DB2 War Stories and Scary Tales
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

DB2 War Stories and Scary Tales

on

  • 652 views

 

Statistics

Views

Total Views
652
Views on SlideShare
652
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Welcome. Come on in.
  • Major Points to be Covered * Database foundation stones * SQL Exposures * Questionable philosophies * DDL exposures * Operational exposures
  • DB2 for z/OS is the premiere database in the world. We’re bullish on DB2
  • The database principles of integrity, security, recoverability, concurrency, performance and scalability are the foundations stones of modern databases. Over time, DB2 enhancements have offered new functions and facilities which can compromise these foundation stones. Understanding potential risks are and how to avoid them is critical to avoiding problems.
  • We will look at four categories of interest including; deferred restart, trigger overhead, the alter rotate process and the affect of extents on performance.
  • Chapter 1 – Deferred restart of DB2 and the affect of long running units of work.
  • DB2 can stop by crashing, DB2 STOP MODE(QUIESCE) or DB2 STOP MODE(FORCE). When DB2 crashes or is stopped with FORCE, there may be incomplete units of work (UOW). DB2 restart first starts the other database regions (IRLM, DM, DDF). In the next step unresolved units of work from when the database came down are resolved. After this is complete, DB2 is up and available to applications.
  • This is out story.
  • During the week there was a program that did sparse updates which ran for over two days without committing. During this period several active logs were archived to tape and these active logs datasets were overwritten by new active logs. When DB2 was cancelled with FORCE, the program’s updated tablespaces had incomplete units of work. Because no commit was found, the unit of work needed to be rolled back. The rollback included reading the “undo” records from the logs to apply them. During the recovery process more “do” and “undo” records were written to the active logs to provide recoverability should the restart fail. Multiple tape archive logs had to be applied. This was very slow. When DB2 was cancelled, the recovery was buried even deeper. Once DB2 was restarted and ran to completion (this took many hours) DB2 came up.
  • In the beginning, all incomplete UOWs had to be resolved before DB2 came up and tables were available to applications. A long running UOW could make DB2 come up very slowly. When deferred restart was added to DB2, it changed the behavior of restarts. It allows recoveries to occur for a limited time and then DB2 marks the pagesets which are not yet recovered in a pending status. When DB2 comes up, all tables except for those in recovery pending status are immediately available. The recovery pending pagesets are recovered after DB2 comes up and are not available until then. Long running UOWs still can cause extended outages.
  • We had an event with DB2 V7 when deferred restart failed. This required a conditional restart of DB2 just like the bad old days. So conditional restart doesn’t always work. Be prepared just in case.
  • Chapter 2 – Some in the “ins” and “outs” of using triggers.
  • Qualifying SQL is unaware whether there are triggers or not. Triggers add directly to both the SQL call CPU and elapsed time. Just firing a trigger is about the cost of a FETCH plus whatever SQL the trigger does.
  • This is our story.
  • Multiple triggers fire serially one after another in order of their creation timestamp. Their times are added to the SQL.
  • Invoking stored procedures is an expensive venture.
  • Using triggers with transition tables (before and after images) adds significant overhead when calling stored procedures.
  • All these elements add to the total cost of a trigger and the invoking SQL. These things add up.
  • There are good and bad reasons to use triggers. Here are some generally poor reasons to use them.
  • The only way to modify triggers is to drop and recreate them.
  • When a trigger is dropped, it’s creation timestamp is reset. If there are multiple triggers, this can cause a different order of execution. To get execution order back, it is necessary to drop all triggers and then recreate them in execution order.
  • Triggers are largely invisible executables. Since they are a run time process, they are unknown by the optimizer and explain for determining the invoking SQL’s access path.
  • Breakage of any of the trigger mechanism will cause failure of all SQL that satisfies the trigger condition. An outage on a trigger application table will cascade up to all SQL that cause the trigger to fire. This is a consideration for DBAs. Be careful.
  • We had an instance when a column was added to a table which was involved in a stored procedure trigger. Because the stored procedure was resident, no failure occurred right then. A few days later when the WLM the stored procedure was in shut down, when the stored procedure was invoked and reloaded it failed. All SQL which fired this trigger started to fail. It was necessary to drop the trigger, drop the stored procedure, modify the parameter lists and recreate the stored procedure and trigger. The trigger was especially difficult to drop due to massive failures and contention. DBAs must understand trigger dependencies and plan for outages on busy tables with triggers.
  • Chapter 3 – The ROTATE statement provides a powerful and potentially dangerous new tool.
  • Rotate deletes all rows in the “first partition” and then reuses it by resetting the partition limitkey . This is great way of keeping a set number of partition cycles and then reusing the first partition to make it the last.
  • It is important to query the DB2 catalog and determine the mapping of the logical partitions to the physical partitions prior to doing the ROTATE command. This will reveal which physical partition is the first logical partition. The logical partition numbers are found in SYSIBM.SYSTABLEPART in the LOGICAL_PART column. The first logical partition should be unloaded before ALTER is done to preserve the data. It’s a good idea to do an UNLOAD of the entire table since this command destroys data. If there are lots of rows in the first logical partition, to avoid mass deletes and logging, the target partition can be dummy loaded with a LOAD REPLACE utility on the partition. The ROTATE command does individual deletes which cause lots of logging. This will have an impact on the system if the partition is not emptied first. It is advisable to do this command during a non-peak time to minimize contention. When the ALTER ROTATE command is executed, the newly rotated (RESET) partition is immediately available and no REORG is necessary. It is advisable to do a full image copy of the rotated partition to provide a clean recovery point. Make sure you understand all of the ramifications of ROTATE before using it. Remember ROTATE destroys partition data.
  • When the ALTER TABLE ROTATE DDL is issued, the logical first partition is deleted with an SQL DELETE to empty it. Early on in V8, the datasets were simply reallocated but this lead to some data integrity exposures. Then the limit keys are altered to the new range. Normally this is non-disruptive.
  • Each time you rotate a table, the logical first partition is emptied and the logical and physical partitions shift. The logical partition number is stored in SYSIBM.SYSTABLEPART.
  • Let the story continue.
  • Limitkeys are not enforced in the last partition in tables which use index based partitioning. Therefore, tables using index based partitioning, the last partition can contain data beyond the partition limitkey. Using rotate to convert a table from index based partitioning to table based partitioning will cause the first and last partitions to be put in a REORP pending state. Running ROTATE causes the table to be converted to table based partitioning the first time it is run.
  • Altering the index to not cluster causes DB2 to convert to table-controlled partitioning. Altering the index back to cluster will make the index available and it should function as before. This method is the least disruptive way to convert to table-controlled partitioning.
  • When altering a partition’s limitkeys, that partition and next higher logical partition are put in REORP state which makes the data unavailable. It requires a REORG SHRLEVEL NONE on all REORP partitions to clear their pending statuses. If there is any data in the partitions whose data values exceed the revised limitkeys , these rows will be placed in the DISCARD dataset.
  • Most DB2 commands, DDL and utilities refer to the physical partition number. There are some exceptions though.
  • It is important to query the DB2 catalog and determine the mapping of the logical partitions to the physical partitions prior to doing the ROTATE command. This will reveal which physical partition is the first logical partition. The logical partition numbers are found in SYSIBM.SYSTABLEPART in the LOGICAL_PART column. The first logical partition should be unloaded before ALTER is done to preserve the data. It’s a good idea to do an UNLOAD of the entire table since this command destroys data. If there are lots of rows in the first logical partition, to avoid mass deletes and logging, the target partition can be dummy loaded with a LOAD REPLACE utility on the partition. The ROTATE command does individual deletes which cause lots of logging. This will have an impact on the system if the partition is not emptied first. It is advisable to do this command during a non-peak time to minimize contention. When the ALTER ROTATE command is executed, the newly rotated (RESET) partition is immediately available and no REORG is necessary. It is advisable to do a full image copy of the rotated partition to provide a clean recovery point. Make sure you understand all of the ramifications of ROTATE before using it. Remember ROTATE destroys partition data.
  • If limitkeys are chosen wisely and do not need to be altered down and tables use table based partitioning, then ROTATE should be non-disruptive.
  • Knowing is half the battle when it comes to safety when using ROTATE. Pay careful attention to the dangers above.
  • More answers on ROTATE. Pay attention.
  • Chapter 4 – Extents may not be as important as they were in the past, but stay tuned to find out while
  • Going to z/OS to get new extents is a relatively slow process. With the new improvements like extent consolidation, they are less of a problem than they were in the past.
  • Here’s our next story.
  • In the days the MVS the concepts of tracks and cylinders match the physical disk. With 21 st century DASD subsystems, RAID technologies and virtualization, many of these concepts no longer match DASD reality. However we are still bound by their rules.
  • The rules of z/OS have changed to provide relief from many of the constraints of the past. We still have to follow the z/OS rules however.
  • IBM has move to relieve many of the limits put on dataset extents. But problems still exist.
  • Our utility benchmarks showed that utilities which create new extents are slowed considerably by a high number of extents. We tried to achieve 200 extents but extent consolidation resulted in only 85 extents. Utilities with 85 extents ran up to 5 times slower. On larger tablespaces, the elapsed time differences would get proportionally smaller. Increase the likelihood of job failure Larger tables difference in times reduced Difficult time due to extent consolidation – tried to get 250 extents
  • To avoid extent issues, there are a number of strategies. DASD fragmentation and slow allocations continue to be problems. We use different strategies for different environments to solve these problems. Ultimately, it would be nice if IBM sped up the z/OS allocation process.
  • Please fill out your evaluation.
  • Thanks for coming.

DB2 War Stories and Scary Tales Presentation Transcript

  • 1. DB2 War Stories and Scary Tales (Part 1) Robert Goodman Certified DB2 Professional Certified Business Continuity Planner May 9, 2007 3:00 p.m. – 4:00 p.m. Platform: DB2 for z/OS Session: A11
  • 2. DB2 War Stories & Scary Tales
    • Major Areas
      • Database Foundation Stones
      • SQL Exposures
      • Questionable Strategies
      • DDL Exposures
      • Operational Exposures
  • 3. DB2 on z/OS – A World Class Act! The Fastest Most Dependable Most Secure Highest Performance Most Scalable Database on the Planet! We're Bullish on DB2! DB2 for z/OS
  • 4. Database Foundation Stones New Features & Combinations Can Undermine These Foundations! Understanding the Risks Is Critical! Data Integrity Data Security Data Recoverability Data Concurrency Performance & Scalability
  • 5. Where Shall We Begin?
    • Chapters
      • Fear of Commitment
      • Trigger Happy
      • Rotate Roulette
      • Extents Wide Open
    DB2 War Stories And Scary Tales By DATABASE BOB Think Tank Publications
  • 6. Fear of Commitment Chapter 1
  • 7. Cycling DB2 DB2 Stop Start DB2 Start: IRLM DM DDF Recover: Unresolved URs Apps Up When DB2 Does Lots of Recovery Apps Up Doesn't deferred restart fix all issues? Deferred Restart - Gives Consistent Startup Times DB2 Crash
  • 8. Once Upon A Time In the kingdom of DB2, the time came for a systems downtime. Many tasks had been busy during the week. It came time to cycle DB2. It was cancelled, but was naughty and wouldn’t come down. After two hours, the operator forcefully killed DB2. Maintenance was applied and the system was brought up. DB2 lingered and wouldn’t wake up. After three hours, the operator killed DB2 for a second time. We tried once again to wake up DB2. This time we asked the wizards at IBM how to slay the problem. They declared that we should just let it run. Twelve hours later DB2 came up. Why did it take so long? And can this happen even today?
  • 9. What Happened and Why? Sparse Updating Long URs X X X X X X X DAY1 DAY2 DAY3 Force DB2 Log1 Log2 Log3 Log1 Log2 A1 A2 - DB2 Log Records - 1) Do Records 2) Undo Records DB2 Restart: Recover Incomplete URs DB2 Up A Long Running UR Had to Roll Back Using Archive Tapes & Active Logs
  • 10. DB2 Restart Deferred Restart Gets the Subsystem Up Quicker X Forward Recovery Backward Recovery App App App Log Deferred Restart A1 App Log Applications Access DB (Quicker) App App App X RECP Start DB2 Restart Complete Applications Access DB Start DB2 Restart Complete Forward Recovery Backward Recovery App App App Log Without Deferred Restart A1 App Log App App App App All Recoveries Must Complete
  • 11. Turning On Deferred Restart
    • LIMIT BACKOUT Parameter
      • AUTO – Automatically recovers once DB2 is up
      • YES – RECOVER POSTPONED command resumes recovery
      • NO – Process all inflight and inabort URs
    • BACKOUT DURATION Parameter
      • log records during backward recovery before deferring
    Are These Parameters Set Correctly?
  • 12. DB2 Restart Questions
    • Does deferred restart always work?
      • In rare cases it fails
    • Won’t deferred restart fix all my problems?
      • Normally
      • Deferred pagesets still need recovery
    • What is status of pagesets after restart?
      • Most pagesets are available
      • Deferred pagesets are unavailable
    • What is the exposure?
      • Applications which use deferred pagesets will fail
    • How can we detect long running URs ?
      • DB2 log message - DSNR035I UNCOMMITTED UR AFTER ### CHECKPOINTS
    • Can I automatically cancel long running URs?
      • Netview can be used to do this
  • 13. Trigger Happy Chapter 2
  • 14. The Trigger Concept Program1 Program1 SQL1 Master SQL SQL After Trigger Database Invokes Trigger SQL SQL With Trigger Firing A Trigger - About the Cost of A FETCH
    • Trigger Facts:
    • Programs are unaware
    • Synchronous
    • Part of UR
    • Firing cost of a FETCH
    • Add in trigger SQL
    • Plus cost of trigger work
    • Adds to SQL elapsed
    Create Trigger SQL1
  • 15. Once Upon A Time The king declared that dashboards would help rule the kingdom. This was a daunting task for many programs had to be changed. Triggers came to the rescue, they were quick and easy. Since 1 trigger was good, many were even better. They multiplied like rabbits and soon the whole kingdom was full of triggers. The word came down from on high that things were slow. Many programs were dragging but no changes had been made. They noticed that when triggers were added, darkness descended upon the kingdom. What had gone wrong? And how could it be fixed?
  • 16. Multiple Triggers Program Master SQL Elapsed Time SQL Database Invokes Trigger Multiple Triggers Before Trigger After Trigger After Trigger
    • Multiple Triggers
    • All are synchronous
    • All in UR
    • Multiple trigger’s SQL
    • Fire one after another
    • Fired in timestamp order
    • Serially add to elapsed time
    Multiple Triggers Run in Sequence SQL
  • 17. Triggers & Stored Procedure Program SQL DB2MSTR SQL Elapsed Time SQL Database Invokes Trigger After Trigger DDF Invoke Stored Procedure
    • Triggers & Stored Procedures
    • Synchronous
    • SP program load time
    • SP execution time
    • Can make calls outside DB2
    • Greatly extends total times
    Stored Procedures Add Significant Overhead to Triggers!
  • 18. Stored Procedure w/Transition Tables Program SQL MSTR SQL Elapsed Time SQL Database Invokes Trigger After Trigger DDF Invoke Stored Procedure
    • Using Transition Tables
    • Synchronous
    • Transition tables
      • Create table time
      • Use table time
      • Delete time
    • SP program load time
    • SP execution time
    • Calls outside DB2 time
    • Adds significantly to times
    DM Transition Tables Add Significant Overhead
  • 19. How Expensive Are Triggers? Fire Trigger – Cost of a FETCH + Trigger SQL – Cost of SQL + WHEN – Invoked every time trigger event happens + Transition Variables – Cost of transition table + Invoke Stored Procedure – DDF, Start thread + Resident Stored Procedure – work in SP + Non-Resident Stored Procedure –start SP + work in SP The Costs Add Up! We Used All of the Expensive Options Statement Triggers – Cheapest Row Triggers – Cheap SP Triggers – Expensive SP Triggers w/Trans Vars - Priceless
  • 20. Generally Poor Reasons to Use Triggers
    • Just because they’re quick
    • Lazy man’s solution
    • Easier than changing programs
    • Temp fixes that become permanent
    • For data replication
    • To populate summary tables
    • To enforce simple value constraints
    • To enforce RI constraints
    Misusing Triggers Can Impact Performance! 9) To maintain dashboards (oops!)
  • 21. Modifying Triggers DROP TRIGGER CREATE TRIGGER Update TRIGGER Refresh TRIGGER One Would Think The Reality Triggers - Easy to Create, Can Be Tough to Drop! DROP & CREATE TRIGGER How Triggers Are Maintained
  • 22. Trigger – Firing Sequence Trigger 1 2007-01-01 Trigger 2 2007-01-15 Trigger 3 2007-01-30 1 2 3 Firing Order DROP & CREATE On 2007-02-15 Trigger 1 2007-01-01 Trigger 3 2007-01-30 Trigger 2 2007-02-15 1 2 3 Firing Order Is Sequence Important? Order of Creation is Firing Order “ It is also used to order the execution of multiple triggers.” CREATEDTS SYSIBM.SYSTRIGGERS
  • 23. Who Is Aware of Triggers?
    • Source Awareness
    • Yes - DB2
    • Should Be - DBAs
    • Maybe – Programmers
    • NO – DB2 Utilities
    • Triggering Awareness
    • NO – Applications
    • NO – SQL
    • NO – DB2 Optimizer
    • NO – Explain
    • NO – Resource Limit Facility
    • NO – Constraints
    Triggers Work Outside Programs & Triggering SQL Triggers - A Run-Time Event
  • 24. Invisible Program Dependencies Programs A B C D . . . MSTR DDF DBM1 SQL SQL Trigger TT AT AT AT Stored Procedure AT Calls Outside DB2 Dependencies Make Administration Challenging!
    • Invisible Causes of Breakage
    • Trigger
    • Trigger SQL
    • DDF
    • Transition tables
    • Stored procedure
    • Application tables
    • Calls outside DB2
    • Unavailable resources
    • RI & check constraints
    • Utilities
    • Deadlocks & timeouts
    • Any Break Causes
    • All Triggering SQL to Fail!
    Invisible to Programs
  • 25. Trigger Traps The Scenario 1) Update trigger on TableA Starts resident stored procedure(SP-X) Inserts before image into log – TableB 2) DBA adds column to TableA 3) Days Later - SQL updating TableA starts failing Corrective Actions 1) Drop the trigger (may require down-time) 2) Drop the stored procedure 3) Add column to parameter lists & SQL 4) Recreate the stored procedure 5) Recreate the trigger When DDF reloaded, the resident SP-X the transition variables no longer matched the trigger and SP-X. The trigger had to be dropped & recreated to correct this. SP-X had to be changed to include new column in TableA DBA's Must Know Interdependencies to Avoid Trigger Traps & Outages! Why? Triggers Alters DBA
  • 26. Rotate Roulette Chapter 3
  • 27. The ROTATE Concept Does This Match Your Needs? 1 Oldest Limitkey A 2 Old Limitkey B 3 New Limitkey C 4 Newer Limitkey D Delete Old Data New Last Part Limitkey ROTATE DDL Command 1) Delete Oldest Partition Rows 2) Reuse Oldest Partition 1 Newest Limitkey E
  • 28. Rotating Partitions ALTER TABLE table ROTATE PARTITION FIRST TO LAST ENDING AT ( limitkey s ) RESET; Simple, Beautiful & Non-Disruptive(?)
  • 29. ROTATE In Action ROTATE DDL catg .DSNDB. db.ts. I0001.A00 3 catg .DSNDB. db.ts. I0001.A00 2 catg .DSNDB. db.ts. I0001.A00 4 catg .DSNDB. db.ts. I0001.A00 1 LP 4 LP 1 LP 2 LP 3 LP 4 LP 3 LP 2 LP 1 First Last After Rotate - Logical & Physical Parts Don't Match! First Logical Partition SYSTABLEPART (V8) Logical Partition After The ROTATE Physical Partition Dataset Last
  • 30. A Series of ROTATEs catg .DSNDB. db.ts. I0001.A00 4 catg .DSNDB. db.ts. I0001.A00 1 catg .DSNDB. db.ts. I0001.A00 3 catg .DSNDB. db.ts. I0001.A00 2 P1 P2 P3 P4 P2 P3 P4 P3 P4 P1 P4 P1 P2 P1 P2 P3 1 st Rotate 2 nd Rotate 3 rd Rotate 4 th Rotate SYSTABLEPART Maps Logical Partitions ALTER TABLE ROTATE ... ENDING AT (‘E’) RESET; Limitkey L1 ‘ A’ ‘ B’ ‘ C’ ‘ D’ L2 L3 L4 ‘ E’ ‘ F’ ‘ G’ ‘ H’ ALTER TABLE ROTATE ... ENDING AT (‘F’) RESET; ALTER TABLE ROTATE ... ENDING AT (‘G’) RESET; ALTER TABLE ROTATE ... ENDING AT (‘H’) RESET; L1 L1 L1 L1 L2 L2 L2 L2 L4 L3 L3 L3 L3 L4 L4 L4 P1 P2 P3 P4
  • 31. Once Upon A Time Version 8 was up and running well. The call came to convert to table based partitioning and reuse the oldest partition. The ROTATE command was chosen to do this non-disruptive deed. Suddenly the phone began to ring and thick darkness covered the database cubicles. A quick check revealed that two parts were mired in REORP status. User processing ground to a halt their workloads were in peril. The database guardians countered with concurrent REORG to fix the problem. This crashed and burned. Share level NONE REORG was called upon. When it finished, the sun came out and life was good again. What happened to disrupt the peace of this database kingdom?
  • 32. Why Did ROTATE Set REORP? SQLCODE = -327 SQLCODE = 0 Last Part Limitkey (‘2007’) Last Part Limitkey (‘2007’) INSERT INTO tableX (D_YEAR) VALUES (‘2008’) Maximum Limitkey in last partition is not enforced by “ index based partitioning” Don't Convert to Table Based Partitioning Using ROTATE! The 1 st time only, ROTATE converts Indexed Based partitioning to Table Based partitioning. Because limitkey is not enforced in Index Based, the 1 st and last parts have to be put in REORP status to eliminate this potential issue. Table_IBP Table_TBP Table Based Partitioning Index Based Partitioning
  • 33. Converting to Table-Controlled Partitioning ALTER INDEX clustering_index NOT CLUSTER; (conversion to table-controlled partitioning) COMMIT WORK; ALTER INDEX clustering_index CLUSTER; (clustering index reestablished) It’s Simple to Do This Before Rotate Limitkey of Last Partition Will Be Converted to Extreme Value!
  • 34. Lowering Limitkeys in Last Part ALTER TABLE table ALTER PARTITION # ENDING AT ( limitkey s ); (This & next partition put in REORP, data outage!) REORG TABLESPACE tablespace SCOPE PENDING SHRLEVEL NONE STATISTICS COPYDDN (Data keys beyond limitkey, discarded during REORG!) Data Outage Conversion to Table Based Partitioning Causes the last part limitkey to be MAXVALUE You Will Have An Outage to Alter Limitkey
  • 35. Which Partition Number is Used? -DIS DB( db ) SPACENAM( ts ) NAME TYPE PART STATUS SRG9700 TS 0002 RW -THRU 0004 SRG9700 TS 0001 RW You Must Know Which Part To Use! Order of Display X -DISPLAY DB X DB2 Datasets X Recover/Rebuild X - Rebalance X Reorg X Load X Unload X Image Copy X Other ALTERs X ALTER ROTATE Logical Part Physical Part Cmd/DDL/Utility
  • 36. Rotating Logical Partitions UNLOAD TABLESPACE tablespace PART ? PP LOAD TABLESPACE tablespace PART ? PP REPLACE using dummy SYSREC -START DB( db ) SPACE ( ts ) PART( ? PP ) ACCESS FORCE COPY TABLESPACE tablespace DSNUM ? PP SHRLEVEL CHANGE (rotated partition now recoverable) ALTER TABLE table ROTATE PARTITION FIRST TO LAST ENDING AT ( limitkey s ) RESET; (1 st LP data deleted, becomes last LP ) Advisable SELECT PARTITION, LOGICAL_PART FROM SYSIBM.SYSTABLEPART WHERE DBNAME = ‘ db ' AND TSNAME = ‘ ts ' AND LOGICAL_PART = 1 1 st LP Logical Part = ? PP Physical Part ? PP 1 2 3 4 5 6 Data Outage Advisable
  • 37.
    • Avoiding Data Outages
      • New Tables – Use “table based partitioning”
      • Last Partition – Don’t set max/min limitkey (may cause -327 SQLCODEs)
    • Converting from “Indexed Based Partitioning”
      • Don’t convert to table based partitioning with ROTATE
        • Use …ALTER INDEX index NOT CLUSTER
        • Then …ALTER INDEX index CLUSTER
      • Plan for Outage on 1 st ROTATE
        • Query for values beyond limitkey before reorg
        • ALTER ASC/DESC limitkey from max/min value
        • Downtime REORG to remove REORP status
    • Know Logical Partitions Prior to Rotate
      • Query SYSIBM.SYSTABLEPART
    Mitigating Rotate Issues Outage
  • 38. Rotate Dangers
    • Knowing which physical part is 1st logical part
    • Long running DELETEs to empty 1 st logical part
      • (42 secs to ROTATE / delete 1,000,000 row partition)
    • ROTATE can cause an outage (REORP status)
      • (convert to table based partitioning or ALTER limitkeys)
    • Which part # to use for Commands / DDL / Utilities
    • Mistakenly rotating the wrong table
      • (DDL reuse or finger fault)
    • Adding partitions to ROTATEd tables
      • (Confusion factor on first & last parts)
    • With ascending keys, trying to insert null key inserts
    • Recoverability after a ROTATE
    • Attempting to REBALANCE ROTATEd tables
  • 39. The Rotate Questions
    • Which partition will rotate next?
      • 1 st Logical partition - query SYSIBM.SYSTABLEPART
    • Does rotate interrupt availability?
      • Yes – if indexed based partitioning (convert to table based, last 2 partitions in REORP)
      • Yes – If last part limitkey is altered
      • No – table based partitioning & limitkey doesn’t need to be altered
    • Can rotate be blocked?
      • Set MAXVALUE in limitkey of last partition
    • Show we use rotate to Convert to Table Based Partitioning?
      • Not advisable (last 2 partitions in REORP)
    • Does rotate behave differently with Index Based Partitioning?
      • Yes - the first time
    • Does rotate rename datasets?
      • No – does SQL deletes instead
    • Does rotate delete SYSCOPY entries?
      • No – puts a rotate row in SYSCOPY
    • If accidentally rotate can I recover?
      • No – rotate row in SYSCOPY prevents recovery prior to ROTATE
  • 40. Extents Wide Open Chapter 4
  • 41. The Extent Concept VOL001 VOL002 VOL003 catg .DSNDB. db.ts. I0001.A00 1 Extent Consolidation 1 st Extent 3 rd Extent 2 nd Extent DB2 requests space from z/OS which finds blocks of space and updates the VTOC and Catalog. Getting Allocations Is Relatively Slow Request 1 Track Request 1 Track Request 1 Track
  • 42. Once Upon A Time Life in the database kingdom was good. Autonomic features had eliminated many servant duties. One day a troubled user called. A table was broken and needed to be recovered. Luckily it had only had five million rows. We proclaimed that it would be back in merely moments. Tapes were mounted, disks were spinning and the clock was ticking. Five minutes turned to ten and then to fifteen. After having many discussions with management, the recovery finally finished. Why did a small table take so long to recover?
  • 43. Extent Evolution Cylinder Track Block 21 st Century DASD 20 th Century DASD z/OS Rules DASD Reality Constrained By z/OS Rules Not DASD Reality! z/OS Rules DASD Subsystem
  • 44. Extent Limits
    • Logical Extent Limits
      • Max Extents / Dataset
        • 255 extents z/OS 1.6
        • 7,257 extents z/OS 1.7
      • Max Extents / Volume
        • 123 extents / volume
        • Large DASD increase this issue (Mod 27s & 54s)
      • Extent Rule
        • 5 pieces primary extent
        • Whatever can get on secondary
    We Must Follow z/OS Rules!
  • 45. Solving Systemic Extent Issues
    • IBM Strategies
      • Tolerate More Extents
        • z/OS 1.7 – 7,257 extents
      • Make It Harder to Hit Limits
        • SMS Extent Consolidation
      • Automate Extent Management
        • V8 Sliding Secondaries
    Some Problems Still Exist!
  • 46. How Extents Affect Utilities (V8) Elapsed Seconds Table 1.2 M Rows and 1 Index Extents Affect Writing Utilities! 16 25 63 256 118 276 305 115 60 45
  • 47. Avoiding Extent Issues
    • DASD Fragmentation
      • STOGROUPs by size
      • Standardized allocations
    • z/OS Slow Allocations
      • Fewer Extents
        • Automated Method
          • Use sliding secondaries
          • Can cause fragmentation
        • Managed Method
          • STOGROUPs by size
          • Standardized allocations
      • From z/OS We Need
        • Faster Allocation Search
        • Faster Cataloging z/OS
  • 48. In Closing
    • Beware
    • Be Knowledgeable
    • Be Careful
    • Do Excellent Work
    Part 2 Is Up To You! Please Fill Out Your Evaluations Want to Hear More? DB2 War Stories And Scary Tales By DATABASE BOB Think Tank Publications
  • 49. Robert Goodman
    • [email_address]
    Session: A11 DB2 War Stories and Scary Tales (Part 1) Thanks for Coming...