During my experimentation with ADDM with Oracle10g on Windows 2003 x64 I found frequent warning at the top of the report, such as:

Significant virtual memory paging was detected on the host operating system.

RECOMMENDATION 1: Host Configuration, 100% benefit (8567 seconds)
ACTION: Host operating system was experiencing significant paging but no
particular root cause could be detected. Investigate processes that
do not belong to this instance running on the host that are consuming
significant amount of virtual memory. Also consider adding more
physical memory to the host.


I knew that this message is likely a bogus one, considering that Windows OS handles virtual memory a bit different than other operating systems. If you launch Task Manager you can easily observe Page Faults rapidly increasing during warm up phase of the Oracle instance (for example after fresh startup):

The other day I found Oracle official explanation:

Note:395957.1 ADDM Reports “Significant Virtual Memory Paging Was Detected On The Host Operating System”

My recommendation is that ADDM advice on Windows platform should be cross checked with OS trying to find out if real memory paging is going on. If you found that for example Oracle process Peak Memory Usage is (was) close to the amount of physical memory, it’s very likely that ADDM warning is not a bogus one and that real memory paging is going on, that need to be addressed.

Today we hit another bug related to Oracle hash group by aggregation. I said another because we already had serious problem with hash group by in 10.2.0.1, as I noted here.
At the moment we’re using 10.2.0.3 Patch 12 and bug is fixed in 10.2.0.5 (and 11.1.07). User encountered bug while processing large dataset with SAS as a front end (extensively utilizing Oracle Analytical functions), on top of that it was during the period of time when server was already under heavy workload.

We’ll try to:

• repeat the error ORA-600 on the same data set with the same tool (SAS) but during off-peak hours. I have a feeling that heavy workload is somehow part of the problem.
• use hint NO_USE_HASH_AGGREGATION within all potential queries. (Con: we’ll see how well will this query work without group by hash feature.)
• disable gby at session level by setting “_gby_hash_aggregation_enabled” to FALSE

I’m certainly not fond to use the same “workaround” as last time by disabling group by hash at instance level, because this time it’s not a “hidden” error and it seems it’s rather sporadic (the same query run well on the same dataset and RDBMS version in the past).

Reference: Metalink Note 6471770.8.

Regards,
AlesK

According to Metalink Note: 578455.1 “Announcement of De-Support of using RAW devices in Release 12G” Oracle will no longer support RAW devices for datafiles, OCR and voting disks. I believe this is a good news considering cumbersome management associated with raw devices – thought not necessarily in all cases and situations.
I’m sure ASM is going to become a mature product by then; perhaps it’s because I’m getting old, but when it comes to changing such critical component as storage management layer I tend to react with caution and conservatism. So far, I survived with cooked file system, avoiding RAW devices, but I’m sure in the long run ASM will be a storage manager of choice, even for non-RAC Oracle customers.