What could be the disadvantage of the "AUTO_SPACE_ADVISOR_JOB" in 10g RAC?

Question

Hi, all.
The database is 2 node RAC database on 32 bit windows 2003 EE SP1.
What could be the pros and "CONS" of the "AUTO_SPACE_ADVISOR_JOB" job
in 10g RAC?
It is one of advisor, and thus I think it is not required.
What could be the disadvantage of AUTO_SPACE_ADVISOR_JOB
in terms of PERFORMANCE in 2 node RAC environment?
The 2 node RAC database seems to be experiencing performance degrade
due to default jobs on installation such as AUTO_SPACE_ADVISOR_JOB and
GATHER_STATS_JOB.
I am looking forwared to hearing your experience and advice.
Thanks and Regards.

Answer 1

Dear Justin.
Thanks for your reply.
1) What is the magnitude of the waits you're seeing? Over what time frame?
--> I found the above wait events in the top 5 wait event section from AWR report.
The AWR snapshot time frame is one hour.
--> On a regular basis(maybe, one or two week), the database hangs, causing a number of library cache related wait events and gc related wait event.
2) If the system is hanging and not doing a log switch, have you debugged that process? I'd be hard-pressed to imagine how library cache events would be related to this sort of thing. I would tend to suspect a hardware/ RAC install/ RAC config issue.
--> I applogize for insufficient information. I took "system state dump" and "hang analyze" at the time of database hang.
--> It is hard for me to understand the system dump file. I reported those files to Oracle Support, but no answer was returned now.
--> As you said, it may be caused by different issues. I will try to investigate other factors.
3) Why do you "guess that when gather_database_stats tries to get statistics about AWR snapshot objects, it causes a number of library cache invalidation and dictionary cache reload between two nodes?"
--> I investigated AWR reports during the period of database hang. I found the above wait events with gather_database_stats in common. That is all why I suspect "gather_database_stats" job.
Specifically regarding the statistics gathering job, is your application is doing something unusual that forces the default statistics job to gather statistics regularly on a substantial fraction of your tables forcing your application to re-parse a substantial fraction of its SQL? Do you have an alternate method for gathering statistics that is going to generate less load and/or invalidate fewer SQL statements? Is your application reusing SQL (i.e. using bind variables)?
--> Currently, we have not deployed all part of an application. At this point, the data is about 10 Mega. The application is using bind variables, but I also could see high number of sql version count. I am inspecting why.
--> I am considering gathering statistics manually (only application schema, not all database objects)
4) What makes you believe that the AWR snapshot process is causing problems?
--> I applogize for insufficient explanation. I mean the problems occur when "gather_database_stats" job takes statistics of "AWR snapshot data",
because application data is very very small, only 10 Mega and 28 tables.
Currently, we have deployed only 1 % of the entire application.
● This is the first time I manage a RAC database. I think a RAC database is something different from a single database.
I do not think the same problem could occur in a single database.
Thanks for detailed explanation and advice.
Best Regards.