Download presentation
Presentation is loading. Please wait.
1
Oracle/AIX Performance and Tuning
UNIX in Focus 2005 Oracle/AIX Performance and Tuning Marc Bouzigues – IBM / Fabienne Lepetit – Oracle /
2
Learning objectives Configure AIX to support Oracle with the best performance Setup Oracle to take advantage of AIX features Understand the joint effort to tune both Oracle and AIX and how they interact
3
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
4
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
5
Oracle Server Architecture overview
Oracle Instance RECO PMON SMON System Global Area Buffer Cache Log Buffer Shared SQL Program Global Area Private SQL Area Dispatcher Processes Dedicated Server Shared Servers Query Servers DBWR LGWR Users D000 Oracle Database DB Files
6
Oracle Server Architecture overview
The components of an Oracle server are : database = set of datafiles (data + redologs + control files) instance = memory structures allocated at startup + background processes (automatically created at startup) associated to a database Database files datafiles – contains data (tables, indexes…) redologs – contains redo entries control files – record the physical structure of the database Oracle memory structures = System Global Area (SGA) + Process Global Area (PGA) SGA shared memory region that contains data and control information for one Oracle instance allocated at instance startup and deallocated at instance shutdown each instance has its own SGA PGA memory buffer that contains data and control information for a server process PGA is created by Oracle when a server process is started contains private SQL area SGA = a shared memory region that contains data and control information for one Oracle instance. Oracle allocates the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA. Process Global Area, often known as the Program Global Area (PGA) resides in the process private memory of the server process. It contains global variables and data structures and control information for a server process. example of such information is the runtime area of a cursor. Each time a cursor is executed, a new runtime area is created for that cursor in the PGA memory region of the server process executing that cursor. PGA is a memory buffer that contains data and control information for a server process. A PGA is created by Oracle when a server process is started. The information in a PGA depends on the Oracle configuration.
7
Oracle Server Architecture – focus on the SGA
The three main components of the SGA are : buffer cache: store the most recently used blocks of data improves performance by reducing disk I/O activity shared pool contains : - shared SQL area (parse tree and execution plan for SQL statements) - dictionnary cache - library cache redolog buffer stores redo entries (log of changes made to the database) written to the online redo log (used during database recovery) SGA = a shared memory region that contains data and control information for one Oracle instance. Oracle allocates the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA. buffer cache – store the most recently used blocks of data. Because the most recently used data is kept in memory, less disk I/O is necessary, and performance is improved. shared pool – The shared pool contains shared memory constructs, A shared SQL area is required to process every unique SQL statement submitted to a database. A shared SQL area contains information such as the parse tree and execution plan for the corresponding statement. A single shared SQL area is used by multiple applications that issue the same statement, leaving more shared memory for other uses. + dictionnary cache redolog buffer - stores redo entries--a log of changes made to the database. The redo entries stored in the redo log buffers are written to an online redo log which is used if database recovery is necessary Process Global Area, often known as the Program Global Area (PGA) resides in the process private memory of the server process. It contains global variables and data structures and control information for a server process. example of such information is the runtime area of a cursor. Each time a cursor is executed, a new runtime area is created for that cursor in the PGA memory region of the server process executing that cursor. PGA is a memory buffer that contains data and control information for a server process. A PGA is created by Oracle when a server process is started. The information in a PGA depends on the Oracle configuration. Library Cache The library cache includes the shared SQL areas, private SQL areas (in the case of a multiple transaction server), PL/SQL procedures and packages, and control structures such as locks and library cache handles. Shared SQL areas are accessible to all users, so the library cache is contained in the shared pool within the SGA. System Global Area Buffer Cache Log Buffer Shared SQL Program Global Area Private SQL Area
8
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
9
AIX VMM Tuning for Filesystems (vmstat or vmo)
MINPERM 15-20%: JFS or JFS2 filesystems without DIO or CIO 5%: RAW logical volumes JFS or JFS2 with DIO or CIO GPFS MAXPERM, MAXCLIENT 40-60%: JFS or JFS2 filesystems without DIO or CIO <= 20%: Raw logical volumes JFS or JFS2 with DIO or CIO GPFS To start, set slightly less than vmtune "numperm" value Reduce until vmstat freed (fr) to scanned (sr) ratio is 4:1 SGA + PGA
10
Virtual Memory Manager (VMM) Tuning – Page Stealing Algorithm
MINFREE 120 x # cpus Increase if page stealing activity vmstat "po" column or vmstat -s "free frame waits“ MAXFREE Set to MINFREE +(MAXPGAHEAD x # cpus) SGA + PGA
11
AIX Memory Tools for use with Oracle
Shared Memory Pinning shared memory – prevents paging out SGA AIX Parameters vmo –p –o v_pinshm = 1 Leave maxpin% at the default of 80% unless the SGA exceeds 77% of real memory Vmo –p –o maxpin%=[(total mem-SGA size)*100/total mem] + 3 Oracle Parameters LOCK_SGA = TRUE Large Page Support vmo –r –o lgpg_size = –o lgpg_regions=(SGA size / 16 MB) Allow Oracle to use Large Pages chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE oracle Large pages can achieve 10 % greater performance.
12
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
13
IO: asynchronous IO (AIO)
Allows multiple requests to be sent without to have to wait until the disk subsystem has completed the physical IO. Utilization of asynchronous IO is strongly advised whatever the type of file-system and mount option implemented (JFS, JFS2, CIO, DIO). Attributes check AIO configuration with : lsattr –El aio0 a rule of thumb : maxservers should be = (10 * <# of disk accessed concurrently>) / # cpu but only tests allow to set correctly minservers and maxservers Monitoring in Oracle’s alert.log file, if maxservers set to low : “Warning: lio_listio returned EAGAIN” “Performance degradation may be seen” #aio servers used can be monitored via nmon (option A) or pstat (pstat –a | grep aios) Use legacy aio. DBWR_IO_SLAVES is relevant only on systems with only one database writer process (DBW0). It specifies the number of I/O server processes used by the DBW0 process. The DBW0 process and its server processes always write to disk. By default, the value is 0 and I/O server processes are not used. If you set DBWR_IO_SLAVES to a nonzero value, the number of I/O server processes used by the ARCH and LGWR processes is set to 4. However, the number of I/O server processes used by Recovery Manager is set to 4 only if asynchronous I/O is disabled (either your platform does not support asynchronous I/O or disk_asynch_io is set to false. Typically, I/O server processes are used to simulate asynchronous I/O on platforms that do not support asynchronous I/O or that implement it inefficiently. However, you can use I/O server processes even when asynchronous I/O is being used. In that case the I/O server processes will use asynchronous I/O. I/O server processes are also useful in database environments with very large I/O throughput, even if asynchronous I/O is enabled. Here are some suggested rules of thumb for determining what value to set maximum number of servers to: The first rule of thumb suggests that you limit the maximum number of servers to a number equal to ten times the number of disks that are to be used concurrently, but not more than 80. The minimum number of servers should be set to half of this maximum number. Another rule of thumb is to set the maximum number of servers to 80 and leave the minimum number of servers set to the default of 1 and reboot. Monitor the number of additional servers started throughout the course of normal workload. After a 24-hour period of normal activity, set the maximum number of servers to the number of currently running aios + 10, and set the minimum number of servers to the number of currently running aios In some environments you may see more than 80 aios KPROCs running. If so, consider the third rule of thumb. A third suggestion is to take statistics using vmstat -s before any high I/O activity begins, and again at the end. Check the field iodone. From this you can determine how many physical I/Os are being handled in a given wall clock period. Then increase the maximum number of servers and see if you can get more iodones in the same time period.
14
IO: mount options (DIO, CIO)
Direct IO (DIO) – introduced in AIX 4.3. Data is transfered directly from the disk to the application buffer, bypassing the file buffer cache hence avoiding double caching (filesystem cache + Oracle SGA). Emulates a raw-device implementation. To mount a filesystem in DIO, use the filesystem mount option “–o dio” $ mount –o dio /data Check with ‘mount’ command Concurrent IO (CIO) – introduced in JFS2 in AIX 5.2 ML1 Inode lock acquired in read-shared mode for read and writes accesses. Implicit use of DIO. Performance achieved using CIO is comparable to raw-devices. To mount a filesystem in CIO, use the filesystem mount option “–o cio” $ mount –o cio /data CIO: JFS2 uses a read-shared, write exclusive inode lock (multiple readers can access simult. the file but when write access is made, a lock in exclusive mode must be held) write serialization at the file level. Oracle, for example, implements its own data serialization which ensure that dara inconsistencies don’t occur. So, it doesn’t need the file-system to implement this serialization. For such applications AIX 5.2 offers CIO. With CIO, multiple threads can simult. perform reads and writes on a shared file.
15
IO: AIO and mount options on JFS, JFS2, raw-device
Ability to implement AIO, DIO, CIO on JFS, JFS2, raw-device Ability to implement AIO Ability to implement DIO Ability to implement CIO JFS OK N/A JFS2 Raw- device N/A (DIO is a mount option for file-systems) N/A (CIO is a mount option for file-systems)
16
IO: AIO and Oracle parameter
How to set filesystemio_options parameter Possible values ASYNCH : enable asynchronous I/O on file system files (default) DIRECTIO : enable direct I/O on file system files SETALL : enable both asynchronous and direct I/O on file system files NONE : disable both asynchronous and direct I/O on file system files Advice : set this parameter to ‘asynch’ - except when filesystem is mounted with DIO, in this case, set it to ‘setall’… Note : set the disk_asynch_io parameter to ‘true’ as well
17
IO: implementation advices
Bench throughput over run duration – higher tps indicates better performance. to get the best performance use JFS2 + CIO (~ equivalent to performance on raw-device) Oracle files : database datafiles should be stored on JFS2 + CIO redologs should be stored on raw-device or JFS2 + CIO (block size 512 bytes) controlfiles should be stored on JFS2 (without DIO or CIO) binaries should be stored on JFS2 (no mount option) if using JFS instead of JFS2, CIO is not available but DIO is – use it. do not allocate a JFS (+DIO) with the large file enabled attribute do not allocate compressed JFS Do not allocate a JFS with the large file enabled (bf) attribute. The big file attribute increases the minimum DIO transfer size from 4K to 128K, forcing Oracle to read and write a minimum of 128K bytes to exploit DIO. The CIO mount option should only be used for filesystems containing data which is intended to be accessed in concurrent mode, such as Oracle datafiles, online redo logs and control files, and should not contain libraries and executables, such as the filesystem containing the $ORACLE_HOME. 512 = OS physical block size
18
IO: how to lay out the database
Stripe and mirror everything (SAME) approach: Goal is to balance I/O activity across all disks, loops, adapters, etc... Avoid/Eliminate I/O hotspots Manual file-by-file data placement is time consuming, resource intensive and iterative Additional advices to implement SAME : apply the SAME strategy to data, indexes separate redologs (+archivelogs) and if possible, undo Use RAID-5 or RAID-10 to create striped LUNs (hdisks) Try to minimize the number of LUNs Create AIX Volume Group(s) (VG) with LUNs from multiple arrays, striping on the front end as well for maximum distribution
19
Database Layout continued
Stripe using Logical Volume (LV) or Physical Partition (PP) striping LV Striping Oracle recommends stripe width of a multiple of Db_block_size * db_file_multiblock_read_count Usually around 1 MB Valid LV Strip sizes: AIX 5.2: 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, 1 MB AIX 5.3: AIX 5.2 Strip sizes + 2M, 4M, 16 MB, 32M, 64M, 128M Use AIX Logical Volume 0 offset (9i Release 2 or later) mklv –T 0 (requires big Volume Groups) e-fix (APAR IY36656) and an Oracle patch (bug ) PP Striping Use minimum Physical Partition (PP) size (mklv -t, -s parms) Spread AIX Logical Volume (LV) PPs across multiple hdisks in VG (mklv –e x)
20
Oracle 10g - Automatic Storage Management (ASM)
New feature of Oracle DB 10g with no additional cost First and only database file system Storage management for Oracle datafiles Alternative to conventional file-system and LVM functions Simplify the database storage administration : on all platforms (Unix, Linux, Windows, zOS) the management of Oracle datafiles is the same for the DBA. ASM manages pools of raw disk Oracle datafiles are automatically striped across all volumes in the applicable ASM pool - I/O is spread evenly across all available disk drives to prevent hot spots and maximize performance Online add/drop of disk devices with automatic online redistribution of data For single or RAC databases Co-existence of ASM and non-ASM files (help migration to ASM) Can maintain redundant copies of data DIO + KAIO
21
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
22
CPU: Simultaneous Multi-Threading (SMT)
new feature available on POWER5 system running AIX 5L version 5.3 allows 2 instruction path to share access to ther POWER5 execution units on every clock cycle instruction path = “virtual processor” = logical POWER5 processor (i.e. a server with 4 physical processors will have 8 logical processors with SMT enabled) SMT allows to use resources that would otherwise usually be unexploited No source code modification needed to use SMT Can achieve significant throughput gains – in the range of 25-40% greater performance. How to control SMT: smtcl [–m on | off] “-w on” enables the SMT mode, “-w off” disables it “-w boot” makes SMT change effective on reboot “-w now” makes SMT change effective immediately but not persistent across reboots
23
CPU Affinity AIX provides a CPU affinity mechanism
Bind process to a CPU by using the binprocessor command Not recommanded for DB or Log writer Ressource set (lsrset, mkrset, rmrset) since AIX 5.2
24
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
25
DLPAR DLPAR extends the capability of LPAR by providing dynamic partition creation Oracle8i and Oracle9i are not DLPAR aware (no dynamic adaptation to system changes) Oracle10g is capable of detecting changes on numbers of processors dynamicaly added (cpu_count parameter) Dedicated partitions are recommanded for strategic workload
26
Micro-Partitioning virtualization
Micro-Partitioning advanced virtualization feature providing micro partition of 1/10th of the physical CPU Oracle sees only virtual processors (x2 if SMT) Can be a performance problem if less physical CPU than virtual CPU (EG 10 vCPU vs 1 pCPU) For system with massive number of partitions use PLM for giving priority to the Oracle partition Sharing adaptor or physical disk is not recommanded for intensive I/O workload Virtual Ethernet is recommanded
27
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
28
DSS/BI, OLTP implementation specificities and advices
SMT (AIX) use as much as possible workload with many processes maximize their perfomances with SMT (e.g. OLTP, DSS with PQO…) Large pages (AIX + Oracle setup) take care to the memory consumption (i.e. if OLTP workload, each process will allocate the size of the granule which is 16M minimum) Shared servers (Oracle setup) Oracle offers an alternative to dedicated servers (1 user / 1 connection to the DB) with the shared servers: n users / 1 connection to the DB. Utilization of shared servers allows to consume less memory and CPU Can be use in case of resource contention with an OLTP workload
29
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
30
Monitoring & tuning methodology
tuning is an iterative process a minimun of changes should be performed at each iteration tuning is a joint effort between the system administrator and the DBA don’t hesitate to keep a log to track changes and the impact of these changes System administrator DBA OS monitoring Oracle monitoring design/parameters changes log of changes impact ?
31
Main monitoring tools for the system
vmstat – useful for obtaining an overall picture of CPU, paging, and memory usage lvmstat – useful to get logical volume I/O statistics iostat – allows to get statistics on disk activity (and also on terminals, CPU, adapters) nmon – complete tool which gives information on all the components of the system filemon – uses the trace facility to report on the I/O activity of physical volumes, logical volumes, individual files, and the Virtual Memory Manager xmperf – allows to define monitoring environments to supervise the performance of the local and remote systems netstat – allows to monitor network activity
32
Monitoring tools for Oracle
Statspack is a standard tool which allow the collection, automation, storage and viewing of performance data. Replaces utlbstat/utlestat. Tkprof allows to take and exploit SQL traces, gives explain plans etc… Oracle Enterprise Manager is a convivial online graphical tool for administration and performance monitoring and analysis. Grid Control (10g) integrates OEM and provide a centralized management of databases. Toad, SpotLight … graphical tools (Quest) Automatic Database Diagnostic Monitor (ADDM) ADDM is a powerful self-diagnostic engine built directly into the kernel of the Oracle database. Using the AWR infrastructure, ADDM is able to analyze holistically the system, provide diagnostic of the major problems identified (not the symptoms), and recommend corrective action (which some times require to use a separate Oracle10g advisor). To focus the attention on the actual problems, ADDM also shows the areas of the system that have no problems. ADDM is invoked automatically every time that a new AWR snapshot is generated (by default every 60 minutes) and the results of the analysis are stored in the AWR repository tagged with the snapshot id. Therefore, the DBA can find historical executions of the advisor and its recommendations. ADDM can be invoked manually for a different set of snapshots by using the ADDM report generator bundled with the software. To generate a new ADDM report execute the following script and pick the sample interval for the analysis: $ORACLE_HOME/rdbms/admin/addmrpt.sql The following is an excerpt of an ADDM report: FINDING 1: 28% impact (97 seconds) Individual database segments responsible for significant user I/O wait were found. RECOMMENDATION 1: Segment Tuning, 28% benefit (97 seconds) ACTION: Run "Segment Advisor" on TABLE "SCOTT.T" with object id RELEVANT OBJECT: database object with id ACTION: Investigate application logic involving I/O on TABLE "SCOTT.T" with object id RELEVANT OBJECT: database object with id RATIONALE: The SQL statement with SQL_ID "5328shb1qxs6u" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID 5328shb1qxs6u insert into a select * from t SYMPTOMS THAT LED TO THE FINDING: Wait class "User I/O" was consuming significant database time. (30% impact [105 seconds])
33
Monitoring & tuning methodology
Performance issue? Monitor the system, diagnose the problem. Tools to use, questions to ask… SYSTEM ORACLE NETWORK netstat CPU vmstat (us, sys, id, r) sar –P ALL nmon CPU bound? runqueue? workload ? parallelization of workload? IO vmstat (wa) iostat, filemon nmon accesses well spread? hot spots? database layout? filesystem mount options? AIO? MEMORY vmstat (pi, po) nmon pagination? memory allocated to Oracle? other applications running? other Oracle instances? init.ora/spfile alert.log bdump,cdump,udump statspack data analyzed? strategy of analyze? memory allocated to instances (SGA, PGA) tkprof (parsing, explain plans, bind variables…) OEM (locks etc…) ( and check ulimits + AIXTHREAD_SCOPE=S...)
34
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
35
Statspack See $ORACLE_HOME/rdbms/admin/spdoc.txt !!
set of SQL, PL/SQL and SQL*Plus scripts allows the collection, automation, storage and viewing of performance data Statspack snapshot : set of statistics gathered at a single time and identified by a unique id. Reports are generated between 2 snapshots. To get a report, two snapshot ids must be provided. The report produced calculates the activity on the instance between the two snapshot specified. In 10g AWR (Automatic Workload Repository) functions in a similarly. It automatically collects and maintains performance statistics. Manual AWR snapshots can also be taken via dbms_workload_repository.create_snapshot(). AWR reports can be generated by running the awrrpt.sql. How to setup and use statspack setup : SQL> connect /as sysdba (interactive script, informations like perfstat username, paswd, tablespace have to be entered) snapshot creation : SQL> connect perfstat/perfstat SQL> execute statspack.snap report generation : #(two snapshot Ids have to be entered) See $ORACLE_HOME/rdbms/admin/spdoc.txt !! Statspack is a set of SQL, PL/SQL and SQL*Plus scripts which allow the collection, automation, storage and viewing of performance data. A Statspack snapshot is a set of statistics gathered at a single time and identified by a unique Id. Once eports are generated between 2 snapshots. The term 'snapshot' is used to denote a set of statistics gathered at a single time, identified by a unique Id which includes the snapshot number (or snap_id). Once snapshots are taken, it is possible to run the performance report providing two snapshot IDs The report produced calculates the activity on the instance between the two snapshot specified. In 10g AWR (Automatic Workload Repository) functions in a similar way as Statspack. It automatically collects and maintains performance statistics. Manual AWR snapshots can also be taken via dbms_workload_repository.create_snapshot(). AWR reports can be generated by running the awrrpt.sql.
36
Statspack Take snapshots regularly during optimization campaign
No shutdown must be done between two snapshots For the generation of statspack report, choose snapshot IDs which are representative of the activity.. # of users simulated time snapshot period analyzed in statspack report For example, during an OLTP benchmark, take snapshots during steady phase… Generate reports to see the impact of tuning and compare behavior of the database according to changes in the configuration It is possible to change the level of statspack to get more detailed information : execute statspack.snap (i_snap_level=>10); Use Metalink and/or the Oracle documentation to get the definition of events, statistics etc…
37
Statspack report: header & hit ratios
STATSPACK report for DB Name DB Id Instance Inst Num Release Cluster Host WABC ORC YES x445r4 Snap Id Snap Time Sessions Curs/Sess Comment Begin Snap: Dec-03 13:15: START-12-LEVEL-7 End Snap: Dec-03 13:39: STOP-12-LEVEL-7 Elapsed: (mins) Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: Redo NoWait %: Buffer Hit %: In-memory Sort %: Library Hit %: Soft Parse %: Execute to Parse %: Latch Hit %: Parse CPU to Parse Elapsd %: % Non-Parse CPU:
38
Statspack report: sections you care about
Top 5 Timed Events list of events to focus on – this ‘top 5’ section will be used to lead the performance investigation Wait Events for DB foreground events – events associated to sessions or client process waiting a resource Background Wait Events for DB background wait events – events associated to background process and also ‘non- background process’ (e.g.: parallel query slave). Allow to orientate the tuning process on a checkpointing issue, IO bound situation… SQL ordered by Gets for DB/... sections ordered according different criterias (SQL ordered by Buffer Gets, SQL ordered by Physical Reads, SQL ordered by Executions, SQL ordered by Parse Calls…). Useful to detect a problem of parsing, IO, CPU… Instance Activity Stats for DB this section gives an overall view of the statistics of the DB. See the Oracle Reference Guide which give the list and description of statistics Tablespace IO Stats for DB sections ordered according IO per tablespace, alphabetically (name of the tbs and name of the file)
39
Statspack report: advisors
Statspack report gives an estimation of the impact of changes of the size of the buffer cache, pga, shared pool (cf buffer pool advisory, pga memory advisory, shared pool advisory) Buffer Pool Advisory for DB: WABC Instance: ORC4 End Snap: 3756 -> Only rows with estimated physical reads >0 are displayed -> ordered by Block Size, Buffers For Estimate Size for Size Buffers for Est Physical Estimated P Estimate (M) Factr Estimate Read Factor Physical Reads D , ,752 D , ,993 D , ,716 D , ,293 D , ,276 D , ,275 D , ,275 D , ,273 D , ,273 D , ,273 D , ,273 D , ,273 D , , ,273
40
Statspack report: sections you care about
Undo Segment Stats statistics about undo activity, snapshot too old etc… Latch Activity for DB this section help the problem determination on latches contention (e.g. : ‘cache buffer chains’ means a hot block issue, ‘shared pool’ indicates an undersized shared pool etc…) Top 5 Logical Reads per Segment / Top 5 Physical Reads per Segment these sections are not included in the report by default but only if the snapshot level is set to 7 or more. Useful section to identify hot spots. SGA Memory Summary this section gives the size of the different structures of the SGA init.ora Parameters this section lists the parameters which are not set by default
41
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
42
Tkprof Tkprof is a diagnostic tool which processes SQL trace output file and translates them into readable output files. It provides a summary of user-level statements and recursive SQL calls and generate execution plans. How to use tkprof set the following init.ora parameters sql_trace = true timed_statistics = true launch the workload get the trace files generated in udump directory /oracle/admin/udump/ $cat *.trc > trace_all.trc use tkprof to format the tracefile tkprof trace_all.trc trace.out explain=system/manager sort=execpu
43
Tkprof bind variable physical reads logical reads
select PEPECODSIT ,PEPENUMPER ,PEPEGESPHY ,PEPEGESMOR ,PEPEENSOI1 into :b1,:b2,:b3,:b4,:b5 From PEPERSON where PEPEIDFSYS=:b8 call count cpu elapsed disk query current rows Parse Execute Fetch total Optimizer goal: CHOOSE Parsing user id: 70 Rows Row Source Operation 4 TABLE ACCESS BY INDEX ROWID PEPERSONCL 8 INDEX UNIQUE SCAN (object id 87722) bind variable physical reads logical reads “execute to parse” ratio explain plan OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows Parse Execute Fetch total COUNT Number of times a statement was parsed, executed, or fetched. CPU Total CPU time in seconds for all parse, execute, or fetch calls for the statement. ELAPSED Total elapsed time in seconds for all parse, execute, or fetch calls for the statement. DISK Total number of data blocks physically read from the datafiles on disk for all parse, execute, or fetch calls. QUERY Total number of buffers retrieved in consistent mode for all parse, execute, or fetch calls. Buffers are usually retrieved in consistent mode for queries. CURRENT Total number of buffers retrieved in current mode. Buffers are often retrieved in current mode for INSERT, UPDATE, and DELETE statements. + The sum of QUERY & CURRENT is he total number of buffers accessed. ROWS Total number of rows processed by the SQL statement. This total does not include rows processed by subqueries of the SQL statement. For SELECT statements, the number of rows returned appears for the fetch step. For UPDATE, DELETE, and INSERT statements, the number of rows processed appears for the execute step.
44
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
45
Most important Oracle parameters
db_cache_size / db_block_buffers shared_pool_size log_buffer pga_aggregate_target / workarea_size_policy sort_area_size log_checkpoint_interval / log_checkpoint_timeout filesystemio_options /disk_asynch_io undo_management / undo_tablespace optimizer_mode Size of the SGA Use pga_aggregate_target instead of sort_area_size. Allow to manage the frequence of the checkpointing. FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform crash recovery of a single instance. When specified, FAST_START_MTTR_TARGET is overridden by FAST_START_IO_TARGET, is overridden by LOG_CHECKPOINT_INTERVAL TFAST_START_IO_TARGET is parameter is deprecated in favor of the FAST_START_MTTR_TARGET parameter. Oracle recommends that you use FAST_ START_MTTR_TARGET instead. Oracle does not recommend using the SORT_AREA_SIZE parameter unless the instance is configured with the shared server option. Oracle recommends that you enable automatic sizing of SQL working areas by setting PGA_AGGREGATE_TARGET instead. Allow to use AIO Use automatic undo_management instead of rollback segments.
46
Agenda Oracle server architecture overview Memory IO CPU
DLPAR & Micro-partitioning DSS/BI, OLTP: implementation specificities and advices Monitoring & tuning methodology Focus on two Oracle tools: Statspack and tkprof Most important Oracle parameters Conclusion
47
Conclusion oraclibm@fr.ibm.com
Implement and get the best of Oracle on AIX is the result of a joint effort between the OS administrator and the Oracle DBA. The tuning process is made of a first guess parameter setting and then, iterations to change progressively the configuration to get the best results… As much as possible, use JFS2 and Concurrent IO mount option Always use Asynchronous IO servers Set AIXTHREAD_SCOPE to S Implement SMT if available on your system Use Large Pages if enough memory available … and feel free to contact us for additional questions!!!
48
Reference material Thanks to the authors of the following documents
Improving Database Performance with AIX Concurrent I/O – S. Kashyap, B. Olszewski, R Hendrickson Performance Management Guide – AIX5L version 5.3 documentation Oracle 9i & 10g on IBM AIX5L : Tips & Considerations – IBM/Oracle ICC Oracle Architecture and Performance Tuning on AIX – R. Ballough Many thanks to Dennis Massanari, Michel Rivière and Majidkhan Remtoula for their help!
49
International Competency Centers
Tokyo, Japan AP IBM Oracle Support Center Proof of concept, sizing and benchmarks San Mateo, California IBM Oracle International Competency Center Sizing methodology and tool development, benchmark coordination and education Montpellier, France EMEA Oracle IBM Support Center Proof of concept, sizing, benchmarks and education All hardware and software brands
50
EMEA Oracle/IBM Joint Solutions Center
A joint team: EMEA Oracle/IBM Joint Solutions Center How the JSC can help Perform benchmarks Demonstrations and customer briefings Workshops and educational events Architecture validation and sizing for Oracle solutions on IBM The JSC is located in the PSSC, the IBM training, benchmarking and support center in Montpellier. The JSC is permanently staffed by Oracle as well as IBM. Its mission is to assist the Oracle and IBM sales divisions. If you have an issue related to IBM and Oracle, the center might be able to help you. Don’t hesitate to contact the JSC! Need to test The JSC can provide you with IBM hardware (pSeries, zSeries, xSeries, iSeries cluster) for tests when performance is not the main issue. Need to validate an architecture Make sure your solution will work and its components are compatible with each other. Need to benchmark Need to run a benchmark or proof of concept? The JSC will be your interface to the IBM benchmarking center in Montpellier and ensure that the test or prototype will run under optimal conditions. Want to demonstrate Use zSeries, pSeries, xSeries, iSeries and Oracle products to show the latest technology level of our products to your customers. …dedicated to your customer projects. Six years of experience
51
JSC Newsflash : a JSC information for the fields
Produced quarterly Last issue ( Januray 2005 ) Audience IBM/Oracle/Partner fields Main contents : Product information from Oracle and IBM Technical and Sales oriented Statistics ( 3 month period ) Number of dowloads : 1079 (Oracle employees = 275, External = 368, Anonymous = 436) Next issue : April 2005 Special Unix in Focus
52
Oracle/IBM at UNIX in Focus 2005
An Oracle Cursus to build your Oracle/IBM projects. Oracle Sessions (Room Joffre C/D) Oracle10g overview – Paul Bramy, Frederic Michiara (Tuesday – 15:50) (Wednesday – 14:20) Oracle/AIX performance and Tuning - Fabienne Lepetit,/Marc Bouzigues (Tuesday – 17:00) (Wednesday – 15:30) Implementing Oracle EBS 11i on AIX/Linux - Paul Bramy (Wednesday -9:40) (Thursday 15:30) Lab (Room Rondelet) 10gRAC technical lab : Implementing 10gRAC-ASM/GPFS – Michel Passet, Thierry Plumeau, Frederic Michiara (Tuesday – 17:00), (Wednesday -12:20) 3-day Booth - JSC team Meet the Oracle/IBM team and discuss projects
53
EMEA Oracle/IBM Joint Solutions Center
C/O Compagnie IBM France Rue de la Vieille Poste 34006 Montpellier Cedex - FRANCE Tel :
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.