Hi guys I confirm, I am not a DBA, yet my last 10 years with Oracle EBS experiments have given me opportunities to learn few facts those are not documented generally.

A general approach towards deploying a new setup/custom development for EBS is 1st developed and tested thoroughly for which a business needs testing environment. To provide such, a DBA “clones” or duplicates the existing environment and this process is called cloning.

A majority of the environments may note have the hardware with same configurations as it is available for the Production, this causes the cloned instances to perform poorly, thus making the entire testing pretty painful.

During the initial stages of learning, I had tough time digesting our part time DBA’s arguments and reasoning for the slowness, tied to the hardware limitations. Our TEST server has dual processors and 20GB memory with more than 3 TB storage that is hooked up to a 1GB network interface.

As my confidence kept on building, I started exploring the database setups and realized the DBA had only allocated 2GB for SGA & 1GB for the PGA. While questioned, he gave me all possible excuses like “Well, your instance doesn’t require more” and so on.

We got rid of him & had another DBA in the due course, who was far better and more experienced handling bigger environments. Yet we had this nagging issues related to the test instance being slow, lagging beyond our extended patience & I started asking oracle communities questions about how to speed up things.

“Not being a DBA” had it’s own limitations. Many instructions were beyond my understanding, many sounded impractical or illogical & finally one day I decided to setup the R12 (12.0.6, 11gR2 database) with 3GB for both SGA, PGA following an old discussion available with asktom.

That was the beginning. Our TEST instance performance improved to a level that, it become difficult to distinguish between the production and test instances when the Production instance is a beast (minimum for our environment) Although, the manual SGA/PGA settings resolved one of the major performance related issues (login page load, opening large forms etc), I was still NOT convinced by the performance (Queries taking long time..). For some other reasons, I had to restart the TEST server (Which usually happens once in many months time) & was amazed to see that the performance gains were distinguishable from earlier times. As soon as I tried to access the instance, the login screen was loaded (not ignoring the cache mechanisms) faster, so did rest of the accesses. Forms based interfaces were loading faster and the queries were returned instantly etc. I opted for another cloning. Dropped the entire R12 instances and repeated the cloning, adjusted the database parameters and “RESTARTED” the physical server, started the database and application tiers and insured that the performance gains I observed were not just a hit and miss, actually a permanent HIT that exists. I continued my experiments further. My next attempt was to upgrade the SGA, PGA with more memory and this time I opted for 4GB for each sector. After the database & application restart I realized the poor performance. I was expecting the instance to be faster! Instead I was dealing with an instance that was as horrible as possible prior to my 3GB/restart patterns. So I rolled back to 3GB SGA, PGA setups and was living with it until our finance consultant asked me for a fresh clone with most recent data. This time I decided to duplicate database using RMAN rather than a traditional cold back restore and cloning. As RMAN duplicate database doesn’t require me to alter the database (as the spfile is already available), all I needed was to run the “adautoconfig” from the application tier and go online. I felt something awkward Although the instance was “Okay”, there were few things which were NOT AT all okay. The database alert log was showing redo log files related issues. I checked the redo log files, things were looking Okay against the documents those I were referring to do the RMAN duplicate database…yet I took the application tier offline and altered the database like following:

1. Increased the SGA max memory to 5GB and target to 4GB, restarted the database (40% of total available memory)
2. Left PGA at 3GB (Thus totaling the memory dedicated for the database to 8GB out of 20GB available)
3. From the database tier, executed “adautoconfig”
4. Execute “adautoconfig” from the application tier
5. Shutdown database and restarted the physical server

Restarted database and application tiers & boom, the instance was once again giving me the buttery smooth experience. I ain’t sure, whether it is technically correct, it was all about executing “adautoconfig” against both tiers after database parameter changes. I will ask Oracle community soon to confirm it. Now, all the above experiments with an obsolete release of Oracle application R12 (12.0.6) over an OS (Linux 6) that’s not supported were performed over many months time. Lack of true technical training must be one of the reasons contributing towards painful experiences. Well, whatever, today I feel like a winner. Just because I am able to host an instance of the application over a hardware that was labelled obsoleted just because someone didn’t know how to fine tune an instance of Oracle application, even though he is certified to do that! If you are like me, not certified, a jack of everything, who loves to keep on experimenting, do give the above a try & post me your experiences! regards, rajesh