1. Database Tuning

2. Objectives Describe the roles associated with database tuning. Describe the dependency between tuning in different development phases. Describe SLAs. Describe appropriate tuning goals. Describe common tuning problems. Describe tuning considerations. Describe performance and safety trade-offs.

3. Tuning methodology Pre 9i top down tuning, post 9i performance tuning principles if top down not appropriate. Traditional approach is appropriate for development systems but new approach is for live systems. Performance tuning is ongoing and iterative process. Requires expertise of DBA and application designers and developers as well as system and network administrators.

4. Top down methodology Tune data design Tune application design Tune memory allocation Tune I/O and physical structure Tune resource contention Tune underlying platform

5. Production system 1. Define problem clearly and identify tuning goals. 2. Examine host system and gather oracle stats. 3. Compare identified problems to common performance problems. 4. Use stats gathered in second step to get a picture of what might be happening in the system. 5. Identify changes to be made and implement the changes. 6. Determine whether objectives identified have been met if yes STOP TUNING if not repeat 5 & 6 again.

6. Goal oriented tuning It is important to set tuning goals and measure progress. Establish benchmarks and base line stats including: Client machine performance Network performance Middle tier application or web server performance Hardware performance OS performance Oracle DB performance

7. Setting performance goals Need to be specific enough to allow quantifiable measures. 5 most frequent PL/SQL packages are always in memory for faster access Response time of a message in server will be less than ½ a second Explicit goals allow: Tuning to be narrow in scope therefore effective Stop tuning process once goal reached

8. Service level agreements (SLAs) Written agreements between DBA and users include: Agreed response times Maximum allowable downtime Recovery time following a failure Can be used to drive performance goals.

9. General tuning concepts Tuning can have a detrimental effect on other areas Faster CPU may improve batch processes but make OLTP slower The batch works faster so is asking for IO quicker so queues start to form. CPU Tuning Oracles memory and IO will give little benefit if CPU is over-loaded Oracle is a CPU aware product and several configuration parameters change dynamically when a CPU is added or removed from the server.

10. Continued... Disk IO The more oracle activity is done in memory (buffer cache) the lower the physical IO will be Increasing buffer cache can make OS page and swap which is a serious overhead Modern disk caching HW and SW complicate DB IO tuning since reads may be from disk cache as well

11. Continued... Memory The availability of memory for Oracles memory structures is key to good performance Memory needs to be managed so that it is used to maximise benefit and not waste it. Network The speed of the network will affect client server systems

12. Common tuning problem areas Poor application SQL Poor DB design Inefficient execution plans Excessive file IO Waiting for DB resources

13. Two tuning guidelines Add more If a resource is being demanded more frequently than they can be supplied then bottlenecks occur e.g. Add more buffers to buffer cache if buffer latch waits occur Make it bigger Problems may occur if a resource is too small If latch waits are occurring on redo logs buffer then you can not add more log buffers but can increase the size of the existing ones

14. Tuning lifecycle Three areas of lifecycle where performance may be impacted in addition to normal running: 1. Application design Excessive normalisation = excessive joins Procedure code v scripts 2. Configuration of new system Benchmarked for each potential configuration 3. Changes in work load If workload patterns change the performance is affected e.g. adding more users or making application available to external users.

15. Review of oracle architecture Oracle DBA needs to completely understand Oracles underlying architecture and mechanisms Before tuning is done, you must understand the relationship between Oracles memory structures, background processes and IO activities

16. Database instance When a database is started the current state of the database is given by the data files, a set of background (BG) processes and memory structures, which is called database instance (DBI) The DBI is a set of memory structures and BG processes that access a set of data files (DFs) Oracles physical file structures are collectively known as the Oracle server.

17. Init.ora Redo logs Archive redo logs Control files Data files Memory system global area DB buffer cache Redo log buffer Shared library client PMON Server processes SMON DBWn CKPT LGWR ARCn

18. Data files (DFs) The database is contained in a number of DFs held on disk When a DB is opened, these DFs and associated BG processes and memory structures are called a DBI. DFs are read via the client process into the memory structure database buffer cache from where the data is processed They are written back to the DFs only by the DBWR process

19. DBWn (DataBase Writers) Except when the database is being recovered it is only the DBW which updates the data files DBW writes blocks from the buffer cache that have been dirtied by various processes DBW tries to make sure that there are always free blocks in the cache for the server process to read data into A commit in a client process does NOT make the DBW write blocks A check point makes the DBW write all current dirty blocks to speed any subsequent recovery

20. Re-do log buffer Changes made to a DB are written to the redo log buffer This is a cyclic buffer and is flushed to the redo log whenever a user process flags a commit or the buffer becomes more than a third full or every 3 seconds Redo logs are fundamental to recovery. Note: the DBW will not write dirty blocks to a data file until the redo log buffer containing the change has been written to the redo log

21. LGWR (Log Writer) Writes redo log entries to the REDO LOG from the redo log buffer Written sequentially (serially) into cyclic redo logs Redo log 1 Redo log 2 Redo Log 3 Redo log 4 Written when log 4 is full the next redo log is log 1

22. Redo Log This records all the changes from the redo log buffer so that a DB can be recovered, it is written to by the LGWR process It is used to recover a DB Roll forward data files from a known point (backup) to any point covered by continuous redo logs Min of 2 used cyclically All redo logs must be kept since the last backup to enable a DB to be recovered Can be queried using log miner.

23. Redo log archiving The LGWR writes the contents of the redo log buffer to the current redo logs When each redo log is full it is closed and the information written to the next log The current redo log is cycled round Redo information wil be lost unless it is written away to a permanent area before the redo log is cycled If turned on process ARCH does this by copying them to the archived redo log area

24. Archive redo logs Archive redo logs and the current redo logs contain the change vectors as far back as the archive logs go If a redo log is missing the the db can only be recovered to the redo log that is missing Hence all redo must be kept from the last successful backup to enable recovery

25. ARCn process The arch process automates the copying of the online redo to the archive area If archiving is turned on current when redo log is closed it is copied to archive area by ARC If not copied by the time the un-archived current redo is cycled DB will STOP until archiving complete Could be due to insufficient room

26. Control files Contains information about the DB including Db name Files and locations System control number of DB and data files Archiving on or off Used to detect and control recovery if SCNs in control file do not match those on data files it knows if recovery needed. Less than 500K in <8i but can be several MB in 9i

27. Initialisation parameters (init.ora) Contains parameters that control the DB instance, read on start up Can include parameters that Name things (e.g. files) Set limits Affect capacity Many parameters can be changed dynamically using alter system or alter session however they are not automatically propagated across on close of DB unless edited in the init.ora SP (server parameter) file in 9i+ allows alter statements to dynamically change parameters.

28. Server parameter file (SP file) These parameter files allow changes applied dynamically to be carried across shutting and opening the DB On startup If pfile is specified the init.ora file is used If no pfile specified then default spfile is used if exists If no pfile specified and no default spfile exists then default init.ora file is used

29. CKPT (Checkpoint) process To minimise the time to recover a DB, Oracle periodically tells the DBW to write all current dirty blocks to the data files This makes the DBW work harder by checkpoints help reduce the amount of work the DB has to do during a recovery When a checkpoint is complete all header blocks in the data and control files have to be updated and a check point entry has to be written to the redo log CKPT updates the headers to reduce impact on DBW

30. PMON – process monitor Monitors the processors running and performs various functions including Performs process recovery when a user process fails Cleans up the cache and frees the resources held by the processes Checks dispatcher and server processors and restarts them if they have failed It is always running if the db is open

31. SGA (Shared Global Area) memory structures Three main memory structures in the SGA area DB buffer cache – a cache of db blocks oracle can not process data unless the block it belongs to is in the cache Log buffers – a buffer of redo vectors being written to the redo logs Shared pool – an area containing information on recently used statements, used to minimise reparsing of statements Very useful for optimisation

32. Have a look at … Look at V$session to identify what processes are running Use V$parameter to identify the value of sga_max_size on the data base (largest the SGA will be allowed to get to)