There is no reason why the du command should report a different size. Some of the hidden files in your output are actually directories. Did you check the contents? The only reason I could think of is a corrupted file system structure.
The OP title says "df" versus "du", which is pretty common, particularly when filehandles of running processes linger for files that have been unlinked from their parent directory: only when the running processes exit will the space be reclaimed by "df". But the thread discussion doesn't seem to involve "df" at all, and also states that OP rebooted the server to no avail.
Best guess in that sceanrio would be that /home/oratest is a mountpoint and perhaps there are some files residing underneath the mount (in the stub directory which ordinarily is empty).
Failing that, a more complete output would help (note that I'm intentionally removing the -h switch to du, to make computing total easier):
root# ls -a |grep -v "\.\." | xargs -n 1 du -sx
... paste all of the output, including the begin and end shell prompts ...
The reason why I wrote "There is no reason why the du command should report a different size." was not related to the df command. The OP computed a different total when using du on a directory compared to using du on individual files in that directory and adding it up. That's why I suggested that there might be hidden files or directories.
The main thrust of my reply was to use "ls" piped to xargs to make sure OP doesn't inadvertently skip any files or directories. My other comments are for posterity should others read the thread and get confused from the subject line's reference to "df" despite the thread being exclusively about "du". Good suggestion regarding lsof, btw...