Oracle actually works hard to avoid file system caches for datafiles (and control and log files) on systems where that can be done. That's the case for AIX and JFS2 with Concurrent I/O (see Administering Oracle Database on AIX for tuning advice too).
The idea is to avoid double-buffering of the data. Oracle caches blocks in the SGA. If the OS caches those too, you've got them twice in RAM which is a waste. And Oracle is supposed to be able to manage its cache more accurately than the OS's cache-replacement policies can - it has more information about the importance/hotness of the blocks with respect to the current workload than the OS does under normal circumstances.
(Oracle also does some very fancy "write buffering" that only the database can do to maintain ACID properties, and needs to control precisely when and what to flush and sync.)
If you've got free RAM, and your Oracle cache hit ratio isn't good, you should consider increasing the size of the SGA (the DB buffer cache in particular). Do look at the
V$DB_CACHE_ADVICE and other tuning views, and keep in mind that you need RAM for other things too (esp. the PGA, but also non-Oracle applications), so don't allocate all your RAM to the SGA.
If you're using Oracle 11g, setting up Automatic Memory Management should be considered so you can set a single target memory size, and let Oracle balance the different areas itself. (For previous release, look into automatic SGA and PGA management.)
As always, test (and benchmark) any changes you make before applying to production systems. And don't starve the OS, leave a "reasonable" amount of memory outside the Oracle memory areas for other needs.
Note that whether the database engine (whichever brand) or the filesystem/OS is the best at caching is an age-old debate. A well-tuned database should be better at caching under normal circumstances. The OS will probably beat a mis-configured database.