TThier/UNIXtips/dynamicReconfig.html Dan Bikle This page is a short discussion of "Dynamic Reconfiguration" aka "DR". Sun.com sells computers (in the SunFire product line) which allow you to configure them while they are "hot". This feature is referred to as "Dynamic Reconfiguration" aka "DR". A link to an in-depth discussion about DR is displayed below: http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-6783-10.pdf The functionality of DR fits well with a feature supplied by Oracle in the database software it ships. The Oracle feature I refer to is "Dynamic SGA". A comprehensive description of Dynamic SGA may be found at the link below: http://technet.oracle.com/products/oracle9i/daily/Aug08.html Solaris 9 (and later versions of Solaris 8) implement two types of shared memory. The default implementation of shared memory is called "Intimate Shared Memory" (ISM). The second type of shared memory implementation is called "Dynamic Intimate Shared Memory" (DISM). Solaris DR and DISM combined with Oracle Dynamic SGA allow a DBA to react to an increase or decrease in load on the database. An obvious question falls out of this discussion, "How does the DBA force Solaris to supply DISM to the Oracle instance?" The answer is, "The DBA forces Solaris to supply DISM to the Oracle instance via use of the init.ora parameter: SGA_MAX_SIZE". Specifically, the DBA needs to set SGA_MAX_SIZE to a value which is larger than the sum of the values of various other init.ora parameters such as DB_CACHE_SIZE, SHARED_POOL_SIZE, and JAVA_POOL_SIZE. In the demonstration associated with this page, I set SGA_MAX_SIZE to the value of 10123456789 which is approximately 10GB. For example, if the load on the database increases, (and SGA_MAX_SIZE is set to a large enough value) the DBA could react by using DR to add CPU and RAM to the host while both the host and database are "hot". Then, the DBA would use the Dynamic SGA feature to expand the memory allocated to and then used by the database. If the load decreases, the DBA would use the Dynamic SGA to shrink the database shared memory structures. At that point he would be done interacting with the database configuration. Next, he would interact with the actual hardware (without actually touching the hardware!). He would use DR to disconnect one or more CPU boards (which removes both CPU and RAM) from the host. In SunFire jargon the host is often referred to as a "domain". For example a SunFire 6800 may be split up into four virtual hosts which would be called domains A, B, C, and D. More discussion about this functionality may be found here: http://www.bikle.com/TThier/UNIXtips/6800domainSetup.html The DBA has several ways to inspect the deployment of CPU boards in a domain: scShowboard.txt prtdiag.txt cfgadm.txt With this discussion behind us, this page will now walk through a simple scenario. Summary: -------- Inspect the hardware configuration of my domain (domain A) -Note that both SB0 and SB1 are "hot" -Make sure I have enough swap to hold the SGA Set init.ora parameters to appropriate values Bounce the database instance -In Production, the instance would now be considered as deployed and must stay up Inspect the database instance memory footprint -Note that it is greater than 8GB Use Dynamic SGA to shrink the footprint to less than 8GB Use DR to disconnect SB1 from domain A Note that Oracle is still functional Use DR to reconnect SB1 to domain A Use Dynamic SGA to expand the footprint to greater than 8GB Note that Oracle is still functional Use Dynamic SGA to shrink the footprint to less than 8GB Use DR to disconnect SB0 from domain A Note that Oracle is still functional Use DR to reconnect SB0 to domain A Use Dynamic SGA to expand the footprint to greater than 8GB Note that Oracle is still functional Details: --------- Inspect the hardware configuration of my domain (domain A) -Note that both SB0 and SB1 are "hot" insp.txt -Make sure I have enough swap to hold the SGA noSwap.txt Set init.ora parameters to appropriate values setInit.txt Bounce the database instance bounce.txt Inspect the database instance memory footprint -Note that it is greater than 8GB footprint.txt Use Dynamic SGA to shrink the footprint to less than 8GB shrink1.txt Use DR to disconnect SB1 from domain A discSB1.txt Note that Oracle is still functional func1.txt Use DR to reconnect SB1 to domain A connectSB1.txt Use Dynamic SGA to expand the footprint to greater than 8GB expSGA.txt Note that Oracle is still functional func2.txt Use Dynamic SGA to shrink the footprint to less than 8GB shrink2.txt Use DR to disconnect SB0 from domain A discSB0.txt Note that Oracle is still functional func3.txt Use DR to reconnect SB0 to domain A connectSB0.txt Use Dynamic SGA to expand the footprint to greater than 8GB expSGA2.txt Note that Oracle is still functional func4.txt General Thoughts ----------------- This page demonstrated a number of general ideas: -It is possible to dynamically alter the memory footprint of a hot Oracle instance -It is possible to dynamically alter the hardware resources of a hot Oracle instance -A hot Oracle instance was forced to travel from one CPU board to another CPU board -Solaris must have access to a swap partition large enough to hold the Oracle SGA -The DBA was shown the exact commands which actualized this demonstration: usefulCommands.txt It should be noted that this testing was done with this version of Oracle: Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.3.0 - Production Solaris info: SunOS bikle 5.8 Generic_108528-23 sun4u sparc SUNW,Sun-Fire The above OS was patched with a Solaris 8 patch cluster I downloaded from here on September 13 2003: http://sunsolve.sun.com/private-cgi/show.pl?target=patches/patch-access Installing the patch cluster was easy: -Download a zip file -Unzip it -cd to the right place -./install_cluster -wait several hours -reboot