Database Tuning
When we talk about database tuning in this sense, we are actually talking about tuning the Oracle Database. Most of the tuning facilities that we have are pre-set on start in a start up file called the init.ora (spfile.ora in 9i). There are over 100 different settings that can be applied to an individual database and it is this multitude of combinations that makes the task daunting. Of these settings, there are probably 50 that constitute the bulk of database tuning, and probably 25 or 26 that are critical. In a production database this can exact a heavy toll on the system if settings are wrong.
And then there are development and UAT (user acceptance testing) databases that are often just mini versions of the production databases. This is because the testers do not need a 60 gig database to work on when a scaled down version that is maybe 15 or 20 gig will suffice. It makes for faster refreshes when you have to start all over again after a period of testing and allows for more instances to be created (you can three development databases into the space of one production database) which allows for different groups to be on different databases without stepping over each other in the process.
Unfortunately, the values that are set in the development databases are often carried over into production which may be a terrible thing to do, since what worked on a small database with a few users won't work on a large database with a hundred users. This is where tuning comes in. What works in one environment doesn't necessarily work in another environment. Or on a different machine. If one machine has 1 cpu and the production one has 4 cpu's and 2 gigs of memory and a RAID5 disk implementation, you can change the settings to take advantage of this.
Want More Information? Please contact us: Ask for more Info