Now my question is what COPY and REORG utilities should I give to make sure both are recoverable to a consistent point using recover utility for each scenarios?
I tried the following.
SCENARIO 1
DEFINED TEMPLATES AND LISTDEF
STEP1: REORG OF BASE TABLESPACE STATISTICS SHRLEVEL NONE LOG NO UNLDDN
STEP2: REORG OF LOB TABLESPACE SHRLEVEL REFERENCE UNLDDN COPYDDN
Code:
LISTDEF REO2
INCLUDE TABLESPACES DATABASE DBDMFP1P LOB
TEMPLATE SREC2
UNIT SYSDA
DSN 'HLQ.DM.REORG.&DB..&TS..SREC'
DISP(NEW,DELETE,CATLG)
TEMPLATE SCOPY2
DSN 'HLQ.DM.FULL.&DB..&TS.(+1)'
DISP(NEW,CATLG,CATLG)
GDGLIMIT(4)
UNIT SYSDA
REORG TABLESPACE LIST REO2
SHRLEVEL REFERENCE
UNLDDN SREC2
COPYDDN SCOPY2
STEP3: REORG OF XML TABLESPACE SHRLEVEL NONE LOG NO UNLDDN
Code:
LISTDEF REO3
INCLUDE TABLESPACES DATABASE DBDMFP1P XML
TEMPLATE SREC3
UNIT SYSDA
DSN 'HLQ.DM.REORG.&DB..&TS..SREC'
DISP(NEW,DELETE,CATLG)
REORG TABLESPACE LIST REO3
STATISTICS TABLE(ALL) INDEX (ALL)
SHRLEVEL NONE LOG NO KEEPDICTIONARY
SORTDEVT SYSDA SORTNUM 8
UNLDDN SREC3
STEP4: FULLIMAGE COPY TO DEFINE COMMON POINT OF CONSISTENCY
Code:
LISTDEF CPY1
INCLUDE TABLESPACES DATABASE DBDMFP1P RI ALL
TEMPLATE TMP1
UNIT SYSDA
DSN 'HLQ.DM.FULL.&DB..&TS.(+1)'
DISP(NEW,CATLG,CATLG)
GDGLIMIT(4)
COPY LIST CPY1 COPYDDN (TMP1) FULL YES PARALLEL(4)
SHRLEVEL REFERENCE
SCENARIO2: STEP1: REORG TABLESPACE (SAME as STEP1 of SCENARIO1)
STEP2: FULLIMAGE COPY TO DEFINE COMMON POINT OF CONSISTENCY (SAME as STEP4 FOR SCENARIO1)
Is the steps followed for SCENARIO1/SCENARIO2 , sufficient to develop a point of consistency? Or should I do REORG SHRLEVEL REFERENCE with inline copy and then a common QUIESCE point? Because when I tried running REORG
SHRLEVEL REFERENCE with inline copy, then I saw in SYSIBM.SYSCOPY, I was not able to see a common RECOVERY point as START_RBA column was not same for all the tablespaces (BASE,LOB,XML).
Also can you confirm if I am doing REORG with SHRLEVEL NONE and UNLDDN, then the REORG is restartable without any data loss?
Separating out Base & LOBs is a good idea. But, LOBs are not reorg'd very frequently, unless there is a really really a big peformance problem.
SCENARIO 1 : STEP3 : SHRLEVEL NONE LOG NO on LOB tablespace <-- Bad Idea
Is there any reason for doing a REORG with SHRLEVEL NONE, since the world is moving towards 24x7 applications(CHANGE, if that's not possible REFERENCE).
Code:
INCLUDE TABLESPACES DATABASE DBDMFP1P RI ALL
What about application RI's ?
Scenario2 is better than Scenario1 for regular house-keeping.