Sorry, I shouldn’t be so sarcastic, but try to show some sympathy for my schedule.
Thursday 9th August
22:30 BST – Go to bed, unusually early.
Friday 10th
06:00 BST – Wake up, check Netvibes and noticed several 11g release blogs, including Eddie’s initial notification and Howard’s installation!
07:30 BST – Leave for my current client site. There’s no blogging there. It is work after all 😉
08:00 BST – However, in the interests of everyone there, I sent a notification to the rest of the DBAs and started to investigate the documentation and any license implications in particular. However, as an AIX site, and considering the professional support levels that are required, it will be a long time before it’s used in earnest. The first two things I noticed that were relevant to my previous comments were that Total Recall will be an additional cost option and that there’s a supported way of turning off ASH!
Talking about Total Recall first, I’m not surprised. It highlights that this might not be the minor Flashback enhancement that it might appear, but a show-stopping feature that might (for all I know) require some patent license payments, although I’m really not an expert on that!
As for a supported way of disabling ASH … I sent a note to myself to blog about that when I got home. By the time I got there, it had cropped up on the Oak Table list and it looks like the CONTROL_MANAGEMENT_PACK_ACCESS parameter does disable the features completely.
Saturday 11th
06:00 BST – Wake up and check Netvibes. Wow, there really are a lot of 11g release blogs, aren’t there? Then I checked the Oracle-L digest and noticed that both issues I planned to blog about had been covered there already.
Fancy a punchline? As the proud possesor of Solaris 10 and Vista Oracle installations, I’ll need to either get Linux sorted out over the weekend (unlikely) or plead with other bloggers to try the control_management_pack_access parameter and let me know if the MMON and MMNL processes disappear.
I do doubt my geek credentials, though, because I can live without an 11g banner this weekend.
Nope – the processes don’t go away even after a database bounce …
sys@ORA11GR1> @param
Enter value for param_name: control_management_pack_access
NAME VALUE DEF DESCRIPTION
—————————— ——————– ——— ————————————————–
control_management_pack_access DIAGNOSTIC+TUNING TRUE declares which manageability packs are enabled
sys@ORA11GR1> !ps -ef | egrep -i “mmon|mmnl”
oracle 9249 1 0 16:08 ? 00:00:00 ora_mmon_ORA11gR1
oracle 9251 1 0 16:08 ? 00:00:00 ora_mmnl_ORA11gR1
oracle 9372 9335 0 16:10 pts/2 00:00:00 /bin/bash -c ps -ef | egrep -i “mmon|mmnl”
oracle 9374 9372 0 16:10 pts/2 00:00:00 egrep -i mmon|mmnl
sys@ORA11GR1> alter system set control_management_pack_access = NONE scope=memory
2 /
System altered.
sys@ORA11GR1> !ps -ef | egrep -i “mmon|mmnl”
oracle 9249 1 0 16:08 ? 00:00:00 ora_mmon_ORA11gR1
oracle 9251 1 0 16:08 ? 00:00:00 ora_mmnl_ORA11gR1
oracle 9472 9335 0 16:12 pts/2 00:00:00 /bin/bash -c ps -ef | egrep -i “mmon|mmnl”
oracle 9474 9472 0 16:12 pts/2 00:00:00 egrep -i mmon|mmnl
sys@ORA11GR1> alter system set control_management_pack_access = NONE scope=both
2 /
System altered.
sys@ORA11GR1> !ps -ef | egrep -i “mmon|mmnl”
oracle 9249 1 0 16:08 ? 00:00:00 ora_mmon_ORA11gR1
oracle 9251 1 0 16:08 ? 00:00:00 ora_mmnl_ORA11gR1
oracle 9505 9335 0 16:12 pts/2 00:00:00 /bin/bash -c ps -ef | egrep -i “mmon|mmnl”
oracle 9507 9505 0 16:12 pts/2 00:00:00 egrep -i mmon|mmnl
sys@ORA11GR1> shutdown
startup
Database closed.
Database dismounted.
ORACLE instance shut down.
sys@ORA11GR1> ORACLE instance started.
Total System Global Area 849530880 bytes
Fixed Size 1303216 bytes
Variable Size 390073680 bytes
Database Buffers 452984832 bytes
Redo Buffers 5169152 bytes
Database mounted.
Database opened.
sys@ORA11GR1> !ps -ef | egrep -i “mmon|mmnl”
oracle 9552 1 1 16:13 ? 00:00:00 ora_mmon_ORA11gR1
oracle 9554 1 0 16:13 ? 00:00:00 ora_mmnl_ORA11gR1
oracle 9609 9335 0 16:13 pts/2 00:00:00 /bin/bash -c ps -ef | egrep -i “mmon|mmnl”
oracle 9611 9609 0 16:13 pts/2 00:00:00 egrep -i mmon|mmnl
sys@ORA11GR1> @param
Enter value for param_name: control_management_pack_access
NAME VALUE DEF DESCRIPTION
—————————— ——- ——— ————————————————–
control_management_pack_access NONE FALSE declares which manageability packs are enabled
sys@ORA11GR1>
Did you spot the parameter parallel_io_cap_enabled ? Looks like you’ve got some more Parallel Execution research to do 😉
Andy
Thanks, Andy. I suppose there are other tests of whether they’re actually doing anything. I’d not really thought it through much 😉
Looks like you’ve got some more Parallel Execution research to do 😉
Tell me about it! 😉
control_management_pack_access and mmon also covered by Howard here:
http://www.dizwell.com/prod/node/936
M.
Surprisingly, it looks like at least some of the collection activities are disabled by setting the parameter to NONE.
I did a post that discussed the control_managment_pack_access parameter here http://kerryosborne.oracle-guy.com/2008/10/oracle-management-packs/ but I only looked at the AWR data collection and when the parameter is set to NONE the snapshots continue to fire but do not appear to collect any data.