Myth busters - performance tuning 103 2008


Published on

Published in: Technology, News & Politics
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Myth busters - performance tuning 103 2008

  1. 1. December 2008 MythBusters - performance tuning 103 Paul Guerin Bachelor of Engineering (Computer) Oracle DBA Certified Professional DBA 10+ years Employers: Origin Energy, Bluescope Steel, BHP Billiton
  2. 2. Topics <ul><li>Capacity Waste and contention. </li></ul><ul><li>NETS performance initiatives. </li></ul>
  3. 3. How data is stored <ul><li>Data is stored in a table. A database contains many tables. </li></ul><ul><li>Tables are comprised of blocks (Oracle: 2k,4k,8k,16k,32k bytes) </li></ul><ul><ul><li>Ideally place as many rows in each block as practical. </li></ul></ul><ul><ul><li>In NETS an average row is 75 bytes long, but many are <40 bytes and >150 bytes. </li></ul></ul><ul><ul><li>Can be 10s or 100s of rows in each block. </li></ul></ul><ul><ul><li>NETS: ~1000 application tables. </li></ul></ul><ul><ul><ul><li>Tables are not sorted - inserts are placed where there is space available. </li></ul></ul></ul><ul><li>Indexes are also comprised of blocks </li></ul><ul><ul><ul><li>An index is a copy of a table column or concatenated table columns. </li></ul></ul></ul><ul><ul><ul><li>Indexes are sorted ascending (default) or descending column. </li></ul></ul></ul><ul><ul><ul><li>NETS: ~800 application indexes. </li></ul></ul></ul><ul><ul><ul><li>Inserts into an index must preserve the sort order. </li></ul></ul></ul>
  4. 4. Waste from Indexes <ul><li>Everyone loves indexes….. </li></ul><ul><li>Indexes are often created to improve query performance, but misuse wastes capacity…. </li></ul><ul><li>Example </li></ul><ul><li>TX.EVENT_QUEUE : 6453 blocks used (~100MB) </li></ul><ul><li>6420 blocks (99.5%) are free most of the time. </li></ul><ul><li>I/O profile: 1.7million inserts occur around the 20th of each month. </li></ul><ul><ul><li>CBO statistics will be inaccurate at this time – not an issue. </li></ul></ul>
  5. 5. Waste from Indexes <ul><li>Example: TX.EVENT_QUEUE </li></ul><ul><li>TX.EVENT_QUEUE_IDX1 (EVENT_HANDLER_TYPE_ID, DAY, CONTRACT_ID, SITE_ID, TNI_CODE, STATE, STATUS, EVENT_QUEUE_ID) = 101MB </li></ul><ul><li>TX.EVENT_QUEUE_IDX2 (EVENT_HANDLER_TYPE_ID, PRIORITY, CREATED_DATE) = 54MB </li></ul><ul><li>TX.PK_EVENT_QUEUE (EVENT_QUEUE_ID) = 24MB </li></ul><ul><li>Total=179MB </li></ul>
  6. 6. Waste from Indexes <ul><li>Example </li></ul><ul><li>Dropped - TX.EVENT_QUEUE_IDX1 </li></ul><ul><li>Dropped - TX.EVENT_QUEUE_IDX2 </li></ul><ul><li>Retained - TX.PK_EVENT_QUEUE (EVENT_QUEUE_ID) = 24MB </li></ul><ul><li>Created - TX.EVENT_QUEUE_IDX (EVENT_HANDLER_TYPE_ID, DAY) = 31MB </li></ul><ul><li>Waste reduction = 179 - 55MB = 124MB </li></ul><ul><li>Waste was greater than the size of the table (ie master data~100MB) !!! </li></ul><ul><li>Poor index placement leads to: </li></ul><ul><ul><li>Wasted capacity </li></ul></ul><ul><ul><li>Inefficient execution plans leading to poor performance. </li></ul></ul>
  7. 7. <ul><li>Table inserts: </li></ul><ul><ul><li>Each table contains blocks available for insert. These blocks are identified in a freelist. </li></ul></ul><ul><ul><li>Default: A block is i) available for an insert if <40% full. ii) not available for an insert if >90% full. </li></ul></ul><ul><ul><li>Also each table has a High Water Mark (HWM) to indicate the maximum number of blocks that contained rows. </li></ul></ul><ul><ul><li>Index: Row is inserted in the correct place in the leaf block. </li></ul></ul><ul><li>Table deletes: </li></ul><ul><ul><li>Table blocks that fall underneath the lower threshold (default: 40%) are placed on the freelist. </li></ul></ul><ul><ul><li>Index: Row is also deleted. </li></ul></ul>
  8. 8. Waste from nologging inserts <ul><li>All Inserts/deletes/updates generate archive logs (SQLserver: transaction logs) </li></ul><ul><ul><li>Archive log: a record of changes that occurred in a database. </li></ul></ul><ul><ul><li>Required for data recovery. </li></ul></ul><ul><ul><li>Exception: Can perform a nologging insert with an Append hint. </li></ul></ul>
  9. 9. Waste from nologging inserts <ul><li>Nologging inserts (also known as a Direct Path Load) </li></ul><ul><ul><li>The insert is always performed above the High Water Mark of the table. </li></ul></ul><ul><ul><li>Advantages: </li></ul></ul><ul><ul><li>Less overhead leading to potential increase in overall database performance. </li></ul></ul><ul><ul><li>Insert compressed rows into a table - can't use a normal insert to compress. </li></ul></ul><ul><ul><li>Disadvantages: </li></ul></ul><ul><ul><li>Nologging inserts are not cached in memory. </li></ul></ul><ul><ul><li>Redo entries still created for any indexes on the table. </li></ul></ul><ul><li>Potentially wastes space as free blocks below the HWM are not reused after a delete. </li></ul>
  10. 10. Methods to delete everything from a table <ul><li>i) DELETE TABLE … </li></ul><ul><ul><li>Creates redo entries and a possible performance inhibitor for a large table. </li></ul></ul><ul><ul><li>Also can be CPU capacity intensive. </li></ul></ul><ul><ul><li>No extent deallocation takes place – so the table and index do NOT shrinking and the tablespace does NOT shrink. </li></ul></ul><ul><ul><li>HWM remains as is. </li></ul></ul><ul><ul><li>*** Potential wastage of CPU capacity and storage space due to archive log creation *** </li></ul></ul><ul><li>ii) DROP TABLE … </li></ul><ul><li>CREATE TABLE … </li></ul><ul><li>CREATE INDEX1, CREATE INDEX2, etc … </li></ul><ul><ul><li>Deallocate extents from table and indexes but re-allocate for inserts. </li></ul></ul><ul><ul><li>Deallocation/allocation is a performance inhibitor. </li></ul></ul><ul><ul><li>The tablespace does NOT shrink. </li></ul></ul><ul><li>iii) TRUNCATE TABLE … </li></ul><ul><ul><li>Deallocate extents from table and indexes (default: DROP STORAGE) but re-allocate for inserts. </li></ul></ul><ul><ul><li>Resets the HWM. </li></ul></ul><ul><ul><li>Tables and indexes shrink – but the tablespace does NOT shrink. </li></ul></ul><ul><ul><li>??? DDL becomes severely slower where the number of extents >4096 ??? </li></ul></ul><ul><li>iv) TRUNCATE TABLE … REUSE STORAGE </li></ul><ul><ul><li>Arguably the best option as extents are not deallocated – why deallocate if just going to allocate on insert? </li></ul></ul><ul><ul><li>Resets the HWM. </li></ul></ul><ul><ul><li>Tables and indexes do NOT shrink – the tablespace also does NOT shrink. </li></ul></ul>
  11. 11. <ul><ul><li>Myth: Tablespaces do not extend. </li></ul></ul><ul><ul><li>Each tablespace will extend to its natural limit. e.g. NETS = 16GB. </li></ul></ul><ul><ul><li>To extend beyond the limit another datafile or tempfile must be added. </li></ul></ul><ul><ul><li>More tempfiles are needed if the workspace in memory and disk is exceeded. </li></ul></ul><ul><ul><ul><li>Large or inefficient queries need larger workareas - more waste. </li></ul></ul></ul><ul><ul><li>Myth: Oracle doesn’t reuse space. </li></ul></ul><ul><ul><li>Oracle does reuse space (on table freelists) but…. </li></ul></ul><ul><ul><ul><li>Nologging inserts will waste space if misused. </li></ul></ul></ul><ul><ul><ul><li>Indexes may waste more space than a table. </li></ul></ul></ul><ul><ul><li>Myth: Truncates, Drops, and Deletes free space. </li></ul></ul><ul><ul><li>Truncates and drops only deallocate space to the tablespace, not to the storage medium. </li></ul></ul><ul><ul><li>Deletes only free space within the table (and any indexes). </li></ul></ul><ul><ul><li>For a delete the table (and any indexes) do not shrink in size - even if every row has been deleted. </li></ul></ul>
  12. 12. Waste from statement processing <ul><ul><li>Myth: Inserts/deletes/updates lock the whole table. </li></ul></ul><ul><ul><li>Myth: Oracle escalates locks. </li></ul></ul><ul><ul><li>In Oracle, writes to a table don't block reads to the same table. </li></ul></ul><ul><ul><li>Oracle doesn't have a lock manager (unlike SQLserver and DB2). </li></ul></ul><ul><ul><ul><li>Locks are stored with the data. </li></ul></ul></ul><ul><ul><ul><li>Therefore Oracle can not escalate locks. e.g. several row locks consolidated into a whole table lock. </li></ul></ul></ul><ul><ul><li>Also locks occur at block level (“hot block”) where a session attempts to read a block that another session is already reading from disk. </li></ul></ul><ul><ul><ul><li>e.g. multiple PKG_EVENT_QUEUE.DO_DAY_EVENT queued jobs concurrently reference TX.TNI_CUST_AGG_DATA. </li></ul></ul></ul><ul><ul><li>The wait time for a “hot block” is often >50% greater than the read time from disk. </li></ul></ul><ul><ul><li>Therefore multi-session processing leads to slower elapsed times for each session. </li></ul></ul><ul><ul><li>Note: Multi-session processing is NOT the same as parallel processing. </li></ul></ul><ul><ul><li>Significant amounts of time are wasted where multi-session processing occurs. </li></ul></ul>
  13. 13. Waste from excessively large workareas <ul><li>The database is comprised of storage for data and separate allocations for workareas. </li></ul><ul><li>NETS: 473GB (52%) is dedicated to copies (MVs, indexes) or temporary work areas (temporary tablespace, undo tablespace). </li></ul><ul><ul><li>NETS temporary tablespace (~30GB) </li></ul></ul><ul><ul><ul><li>Sorts or hash joins above >25MB spill from memory to disk. </li></ul></ul></ul><ul><ul><li>NETS Undo tablespace (~64GB) </li></ul></ul><ul><ul><ul><li>Need more for long running queries and updates/deletes/inserts. </li></ul></ul></ul><ul><ul><li>GETS Undo tablespace (~102GB) more than 71% of all GETSP datafiles. </li></ul></ul><ul><ul><li>Poor performing queries need larger workareas, therefore more storage capacity. </li></ul></ul>
  14. 14. Reclaiming waste <ul><li>NETS: 442GB (48%) is dedicated to table storage. </li></ul><ul><ul><li>However only 287GB (31%) is actual data. </li></ul></ul><ul><ul><li>Wastage = 442GB – 287GB = 155GB </li></ul></ul><ul><ul><li>Large differential due to sparse blocks (ie few rows per block). </li></ul></ul><ul><li>Solution: Rebuild the tables and indexes to increase block density. </li></ul><ul><li>Method: </li></ul><ul><ul><li>Create new tablespace (initial allocation). </li></ul></ul><ul><ul><li>Rebuild (allocate more): </li></ul></ul><ul><ul><ul><li>Large tables into their own tablespace. </li></ul></ul></ul><ul><ul><ul><li>Indexes and MVs into their own tablespaces. </li></ul></ul></ul><ul><ul><ul><li>Rebuilds of tables require an outage (or at least locking of that table). </li></ul></ul></ul><ul><ul><ul><li>Rebuilds of indexes can be performed online without locking. </li></ul></ul></ul><ul><ul><li>Drop old tablespace (deallocation). </li></ul></ul><ul><ul><li>Note: need more storage space to reclaim storage space. </li></ul></ul>
  15. 15. Reclaiming waste <ul><li>Rebuilds: </li></ul><ul><ul><li>Increase block density and decrease the number of sparse blocks. </li></ul></ul><ul><ul><li>Potentially less physical I/O to get the same data. </li></ul></ul><ul><ul><li>Potentially more rows cached in memory. </li></ul></ul><ul><ul><ul><li>Enhanced when using compressed tables. </li></ul></ul></ul><ul><ul><li>Lower cluster factor so indexes are more likely to be used by the CBO. </li></ul></ul><ul><ul><li>More rows per block can result in better query performance. </li></ul></ul><ul><ul><li>… . However also a chance of poorer query performance: </li></ul></ul><ul><ul><ul><li>Execution plan will change but perhaps for the worse….. </li></ul></ul></ul><ul><ul><ul><li>Similar consequences for other performance initiatives: </li></ul></ul></ul><ul><ul><ul><li>Parameter changes, statistics gather, new index on table, ... </li></ul></ul></ul><ul><ul><ul><li>Corrective action : Affected queries need SQL tuning. </li></ul></ul></ul>
  16. 16. Contention for capacity <ul><li>Wasted capacity is a symptom of poor performance but…. </li></ul><ul><li>contention for capacity can also be significant…. </li></ul><ul><li>All our databases are on shared storage (SAN): </li></ul><ul><ul><li>adv: reliability </li></ul></ul><ul><ul><li>disadv: I/O contention between databases </li></ul></ul><ul><li>Myth: High workloads in the MTMs don't affect NETS. </li></ul><ul><ul><li>All production databases share the same storage. </li></ul></ul><ul><ul><li>I/O processing leads to contention amongst databases. </li></ul></ul><ul><ul><li>Contention for I/O capacity leads to reduced response times on all production databases. </li></ul></ul><ul><ul><li>Soln: SQL tuning to reduce I/O. </li></ul></ul><ul><ul><li>Also datafile rebuilds and compressed objects to reduce the number of blocks required. </li></ul></ul>
  17. 17. Contention related myths <ul><li>“ Can you make my session run faster?” </li></ul><ul><ul><li>Limited ability to prioritise sessions with Windows. </li></ul></ul><ul><ul><li>Other operating systems allow easy setting of process priority for the CPU: </li></ul></ul><ul><ul><ul><li>Solaris/unix/linux: monitoring tools, identify resource utilisation profile, prioritise processes for critical jobs. </li></ul></ul></ul><ul><ul><li>Only queued jobs (not user sessions) can be prioritised in Oracle 10g. </li></ul></ul><ul><ul><li>Limited ability to influence CPU contention between user sessions. </li></ul></ul><ul><li>Myth: All data should be placed on a single database </li></ul><ul><ul><li>Contention for CPU time </li></ul></ul><ul><ul><ul><li>Segregate amongst different hosts. </li></ul></ul></ul><ul><ul><li>Contention for I/O because all hosts on the same SAN: </li></ul></ul><ul><ul><ul><li>SQL tuning or place data on local storage. </li></ul></ul></ul><ul><ul><li>Same database inevitably leads higher workloads, contention on CPU, and poorer performance. </li></ul></ul><ul><ul><li>Placing all data on a single database results in minor savings in storage space. </li></ul></ul><ul><ul><li>Data consolidation leads to more CPU contention. </li></ul></ul>
  18. 18. Good database practices….. <ul><li>SQL tuning: </li></ul><ul><ul><li>Less block retrieval and sorting. </li></ul></ul><ul><ul><li>Less need for large work areas. </li></ul></ul><ul><li>Instance tuning: </li></ul><ul><ul><li>Rightsizing memory components. </li></ul></ul><ul><ul><li>Reducing “hot blocks” and block clones. </li></ul></ul><ul><li>Database tuning: </li></ul><ul><ul><li>Correct index placement. </li></ul></ul><ul><ul><li>Object rebuilds to increase block density. </li></ul></ul><ul><ul><li>Statistics on objects are also important. </li></ul></ul><ul><li>Tip: Less contention on a weekend (>8am <6pm) = faster queries </li></ul>
  19. 19. Operational improvements on NETS <ul><li>Sustained effort to improve NETS operating performance over the past two years. </li></ul><ul><li>Scores of initiatives employed to “clean up the mess”….. </li></ul>
  20. 20. Operational improvements on NETS <ul><li>Query optimisation </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Rule-based optimiser not supported by Oracle - bugs present that will never be rectified. </li></ul></ul><ul><ul><li>Generation of poor execution plans. </li></ul></ul><ul><ul><li>Soln: Gather statistics on all objects </li></ul></ul><ul><ul><li>Better execution plans lead to faster queries. </li></ul></ul>
  21. 21. Operational improvements on NETS <ul><li>Inserting data </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Nologging inserts are not compatible with an online backup strategy. </li></ul></ul><ul><ul><li>Insert only above the HWM - large potential for wastage. </li></ul></ul><ul><ul><li>Soln: Forced redo entries prevents inserts above the HWM </li></ul></ul><ul><ul><li>Forced logging is transparent to the application. </li></ul></ul>
  22. 22. Operational improvements on NETS <ul><li>Performance monitoring </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Difficult to determine which objects are DML intensive. </li></ul></ul><ul><ul><li>Also difficult to view condition of database days later. </li></ul></ul><ul><ul><li>Soln: enable monitoring for each table and take performance snapshots </li></ul></ul><ul><ul><li>Gathering statistics where >10% of changes made to the table. </li></ul></ul><ul><ul><li>Also monitor index usage. </li></ul></ul>
  23. 23. Operational improvements on NETS <ul><li>Security and auditing </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Many schemas had an unrestricted ability to change or drop any object. </li></ul></ul><ul><ul><li>Most schemas had an unrestricted ability to grant any privilege to another schema/user. </li></ul></ul><ul><ul><li>DBA roles and privileges given to schemas and users. </li></ul></ul><ul><ul><li>Some schemas had access to DBA type views. </li></ul></ul><ul><ul><li>Unrestricted access to create public database links. </li></ul></ul><ul><ul><li>A defacto DBA account had been created. ie DBO. </li></ul></ul><ul><ul><li>Soln: over 17,000 grants and revokes in 4 stages </li></ul></ul><ul><ul><li>Improved functionality as direct object privileges are granted instead of system privs via a role. </li></ul></ul><ul><ul><li>Better ability to determine which objects are not accessed (without needing to audit). e.g. ETGWEB schema in NETS. </li></ul></ul><ul><ul><li>Enforce the use of correct dynamic views. e.g. user_tab_partitions instead of dba_tab_partitions. </li></ul></ul><ul><ul><li>Better housekeeping as object location can be restricted. </li></ul></ul><ul><ul><li>Between 90-70 objects invalid instead of 110-90. </li></ul></ul>
  24. 24. Operational improvements on NETS <ul><li>Backups </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Taking a database offline destroys any data that was cached in memory. </li></ul></ul><ul><ul><ul><li>Note: Accessing a block in memory is faster than retrieving from the storage. </li></ul></ul></ul><ul><ul><li>Offline backups prevent access to data (including db links). </li></ul></ul><ul><ul><ul><li>Leads to poor availability, if backup every night then links fail every night. </li></ul></ul></ul><ul><ul><ul><li>As NETS references remote databases, taking a remote database offline every night results in job failures in NETS every night. </li></ul></ul></ul><ul><ul><ul><li>On failure any transaction needs to rollback. ie double the workload for no net result. </li></ul></ul></ul><ul><ul><ul><li>Often rerun urgent jobs during business hours which poor performance due to extra workloads. </li></ul></ul></ul><ul><ul><li>Soln: backup while the database is online </li></ul></ul><ul><ul><li>Now NETS is open at all times - preserving data in memory. </li></ul></ul><ul><ul><li>Improved reliability. </li></ul></ul><ul><ul><li>Parallel file copies reduce the completion time. </li></ul></ul>
  25. 25. Operational improvements on NETS <ul><li>Disaster recovery </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Intensive administrative burden to test data recovery. </li></ul></ul><ul><ul><li>No regular disaster recovery. </li></ul></ul><ul><ul><li>Soln: Use the RMAN utility </li></ul></ul><ul><ul><li>Easy to test the disaster recovery procedure and datafiles. </li></ul></ul><ul><ul><li>The backup files become the new database (don't need twice the storage space). </li></ul></ul>
  26. 26. Operational improvements on NETS <ul><li>Full duplicate </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Intensive administrative burden to provide non-production environments. </li></ul></ul><ul><ul><li>Need to synchronise and fracture the shared storage. </li></ul></ul><ul><ul><li>The production database needs to freeze for several minutes. </li></ul></ul><ul><ul><li>Soln: Use the RMAN utility </li></ul></ul><ul><ul><li>Less administrative burden. </li></ul></ul><ul><ul><li>Now no impact on NETS, also tests datafiles used for disaster recovery. </li></ul></ul><ul><ul><li>Uses a copy of the backup files. </li></ul></ul>
  27. 27. Operational improvements on NETS <ul><li>Partial duplicate </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Administration intensive partial duplicates </li></ul></ul><ul><ul><li>Soln: Use the RMAN utility </li></ul></ul><ul><ul><li>Less administration required. </li></ul></ul><ul><ul><li>Smaller footprint on shared storage. </li></ul></ul><ul><ul><li>e.g. TP database only contains the RETAIL schema. </li></ul></ul>
  28. 28. Operational improvements on NETS <ul><li>Month-end snapshot </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Required all processing on NETS to cease for several hours. </li></ul></ul><ul><ul><li>Slow process as parallel processing is not used. </li></ul></ul><ul><ul><li>After-hours monitoring required by the DBA. </li></ul></ul><ul><ul><li>The hierachy structure of the scripts made improvements complex to implement. </li></ul></ul><ul><ul><li>Soln: Use the RMAN utility </li></ul></ul><ul><ul><li>New method has no impact on NETS processing. </li></ul></ul><ul><ul><li>No impact on Transfer Pricing. </li></ul></ul><ul><ul><li>Improved reliability. </li></ul></ul><ul><ul><li>Parallel processing reduces the completion time. </li></ul></ul><ul><ul><li>Uses a copy of the backup files. </li></ul></ul><ul><ul><li>Also NETS analysis processing reduced from 2 wks to 4 days. </li></ul></ul>
  29. 29. Operational improvements on NETS <ul><li>Future - continue to proactively improve reliability and performance.... </li></ul><ul><li>Capacity planning </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Difficult or impossible to reclaim wastage from low density blocks and nologging inserts. </li></ul></ul><ul><ul><li>Difficult object management if 100s of objects are in the same tablespace. </li></ul></ul><ul><ul><li>Large production environments also result in large development/test environments. </li></ul></ul><ul><ul><li>Soln: Reclaim capacity from the database </li></ul></ul><ul><ul><li>Relocate (and rebuild) objects. </li></ul></ul><ul><ul><li>Less space occupied on the shared storage. </li></ul></ul><ul><ul><li>Smaller backup sizes. </li></ul></ul><ul><ul><li>Smaller test and development environments so they take less time to refresh. </li></ul></ul><ul><ul><li>Improved manageability, and potentially performance. </li></ul></ul><ul><ul><li>Also proved that PSS can be shrunk from 900GB to 200GB. </li></ul></ul>
  30. 30. Operational improvements on NETS <ul><li>Migrate to better O/S </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Windows has difficulty with copying large files. </li></ul></ul><ul><ul><li>No longer acceptable for production databases. </li></ul></ul><ul><ul><li>Larger databases require greater analysis of storage efficiency. </li></ul></ul><ul><ul><li>Soln: Migrate to a non-Windows environment </li></ul></ul><ul><ul><li>Investigate Solaris/Unix/Linux for better reliability and monitoring tools. </li></ul></ul>
  31. 31. Operational improvements on NETS <ul><li>Queued jobs </li></ul><ul><ul><li>Problems </li></ul></ul><ul><ul><li>Some jobs take days to complete due to inefficient processing. </li></ul></ul><ul><ul><li>Many old blocks need to be available until long running jobs complete. </li></ul></ul><ul><ul><li>Require >100GB of Undo tablespace in NETS (+ GETS). </li></ul></ul><ul><ul><li>Dynamic SQL don't use bind variables leading to memory fragmentation. </li></ul></ul><ul><ul><li>Soln: SQL tuning activities </li></ul></ul><ul><ul><li>Reduce CPU utilisation via SQL tuning activities. </li></ul></ul>
  32. 32. Summary <ul><li>Strong correlation between the following: </li></ul><ul><ul><li>Slow query performance. </li></ul></ul><ul><ul><li>Wasted data capacity (including unused indexes, inefficient index placement, redundant objects). </li></ul></ul><ul><ul><li>Low block density (including nologging inserts). </li></ul></ul><ul><ul><li>Excessive temporary workarea (memory and disk) due to sorting. </li></ul></ul><ul><ul><li>Excessive undo workareas (memory and disk) due to slow queries. </li></ul></ul><ul><ul><li>Contention for CPU and I/O capacity amongst sessions. </li></ul></ul><ul><ul><li>Multiple sessions on the same table creating &quot;hot&quot; blocks and block clones. </li></ul></ul><ul><li>Waste in production is duplicated in test and development environments. </li></ul><ul><li>Contention for resources affect all databases. </li></ul>
  33. 33. Summary: <ul><li>NETS is being overhauled and the results so far: </li></ul><ul><ul><li>Higher availability. </li></ul></ul><ul><ul><li>Improved overall database performance. </li></ul></ul><ul><ul><li>Less support group intervention. </li></ul></ul><ul><li>More initiatives to come… </li></ul><ul><li>Improvements in NETS are also replicated in GETS, PSS, MTMs… </li></ul>