Oracle to acquire SUN?

I have seen couple of mails today on freelist group stating about the news, 'Oracle going to acquire SUN'. Umm.. quite interesting deal, one has to wait and see what would be the reaction of HPUX, specially after their (Oracle and HPUX) recent exadata innovation and IBM reaction on this deal.

Read more at http://www.oracle.com/sun/index.html.

Happy reading

Jaffar

Node slave process (pz99) on 10g RAC

We have observed a strange slave process, 'pz99' on our RAC databases for every connection to the database and we were wondering what type of processes are they. Thank god our doubt was cleared without much hassles. According to ML Doc :734139.1 'From Oracle 10g onwards you will find on every node slave processes like pz99. This are the processes that query the gv$ views'

Happy reading

Jaffar

Oracle DB & RAC 10gR2 on IBM AIX : Tips and Considerations by Erik Salander

While browsing this afternoon, I have come across of 'Oracle DB & RAC 10gR2 on IBM AIX: Tips and Considerations'

paper by Erik Salander. Well, if you have any planns to setup RAC on AIX, I recommend you to have a look at this paper.

You can download the PDF@ http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101089

If you wanna need the abstract of this paper before you want to download, here it is:

This paper consolidates the information that needs to be considered when implementing and Oracle Database 10gR2 or Oracle RAC (Real Application Clusters) 10gR2 on AIX 

This paper is written to a level of detail that assumes readers have an in-depth knowledge of AIX , Oracle Database 10g, Oracle RAC 10g and the related products.

Happy Reading,

Jaffar

How to startup RAC database services automatically

As of Oracle 10gR2 (10.2.0.4 patch set) when RAC database is started with 'srvctl start database -d DBNAME', unfortunately, the associated database services do not startup automatially. Therefore,   services must be started manually after the database startup. It could be painfull in some situations, like, when you have many databases running on RAC with daily or weekly cold backup schedule. When services are not up, clients unable to connect to the respective databsases, in case they use the service name to connect to the database.

A possible workaround is to write  FAN server side callouts. You may download perl scripts, 'Start Services on Instance Up' from http://www.oracle.com/technology/sample_code/products/rac/index.html. Its a smaple perl script which can be used to as a FAN Server Side callout to start services when an instanes up event is received on the node. You need to put the scripts under $CRS_HOME/racg/usrco. The PDF contains the procedure how to deploy the scripts, setting permission and other stuff.

In 11g,  When services are already started on some remote nodes, then the startup of the instance on the local node will autostart the services on it.

References:

ML 416178.1: After Srvctl Start Database, Database Services Will Not Start Up Automatically

http://www.oracle.com/technology/sample_code/products/rac/index.html

http://www.oracle.com/technology/products/database/clustering/pdf/twpracwkldmgmt.pdf

http://download-west.oracle.com/docs/cd/B19306_01/rac.102/b14197/hafeats.htm#sthref374

Happy reading,

Jaffar

99% memory consumption on an Idle RAC nodes

We have been observed that the memory consumption on all RAC nodes(8 node setup) on HPUX Superdom (Itaninum II)  servers are consuming almost 99% memory round the clock.  There are no databases running, just Oracle clusterware was installed on these nodes. We would be soon using this setup for our production, thats our plan.

We initially thought there could be a memory leak which is causing the high memory consumption. Upon opening a TAR for this issue, Oracle support suggested that the memory consumption by the clusterware is pretty normal and there is no high memory consumption by any of Oracle CW processes. Shutting down the cluster in order to test the memory consumption doesn't help either as the memory consumption still was the same.

Then, we thought of investigating from OS point of view and we  found out that the OS kernel parameter 'dbc_max_pct' was set to the default value, i.e. 50%.  The general recommendation on most of the environments is 10%. Thank god, its a dyanmic parameter which can be modified without the shutdown. Upon resetting the value to 10%, the memory consumption drastically down from 99% to 35% on all the nodes.

I have also found a very good Metalink Note (68105.1 : Commonly Misconfigured HP-UX Kernel Parameters) which explains the most commonly misconfigured HP-UX kernal parameters. Dears, you are running any databases on HPUX, I strongly recommend you to have a look at this note and make changes accordingly.

Happy Reading,

Jaffar