XML Recover

Click here to load reader

  • date post

    26-Oct-2014
  • Category

    Documents

  • view

    87
  • download

    8

Embed Size (px)

description

recover

Transcript of XML Recover

Overview The accidental deletion of tables or table spaces is one of the most painful experiences in the work of a database administrator. Although most larger IT shops running missioncritical database applications have procedures or tools to deal with such situations, there are still installations without special tools support, or, even worse, there is only little experience or practice with these tools. This article describes a specific situation in a DB2 for z/OS environment, where the customer is happy using the pureXML features of DB2 9 for z/OS and storing XML documents within XML tables. To be safe, regular image copies of the database objects are taken in the production environment. Unfortunately, one of these XML tables was dropped by a DB2 SYSADM in the production environment instead of the table with identical name in the test environment. No additional tools such as IBM's DB2 Log Analysis Tool for z/OS or DB2 Object Restore for z/OS were in place so it was necessary to restore the dropped object manually. Under normal circumstances, this is nothing new for an experienced DBA, because DB2 for z/OS ships with the DSN1COPY utility program. But in this special case, the best practices for using DSN1COPY could not be applied as expected. There are some things to consider if an XML table must be restored with DSN1COPY. The following sections describe the potential challenges in restoring XML tables manually and how to deal with these challenges. You probably will not need this procedure if your installation has recovery tools available. But even if you have recovery tools, you may find it useful to know what makes this kind of recovery so special. First, the following is a short introduction of the DSN1COPY utility program and the characteristics of XML tables and related table spaces. Prerequisites To benefit from this article, you should have some experience with DSN1COPY and should have a basic understanding of the different types of table spaces that DB2 for z/OS provides. To exercise such a recovery scenario in your own DB2 environment, Version 9 or 10 of DB2 for z/OS is required. You may also need some SQL scripts or programs to create your own XML data. See the Resources section at the end of this article for further information.

Back to top The DSN1COPY Utility program Experienced DB2 for z/OS DBAs should be quite familiar with the DSN1COPY utility program. It is shipped as an offline utility with DB2 and allows you to copy VSAM data

sets. By using DSN1COPY, it is possible to clone DB2 table spaces and indexes, and to replace the VSAM data sets of a DB2 object with data sets of an image copy. DSN1COPY does not check whether the structure of the data in the VSAM data sets is consistent with the definition of the DB2 object in the catalog. So you have to be careful when using DSN1COPY for restoring DB2 objects. You also have to consider the physical characteristics of the table space when coding the JCL for DSN1COPY. DSN1COPY is suitable as a tool for restoring dropped objects because standard DB2 recovery procedures do not apply in this case. Once an object is dropped, all the information about the image copies is removed from the DB2 catalog and directory. So even the fact that image copies still exist does not help for standard recovery. The DB2 objects must be recreated with SQL DDL first and then the underlying VSAM data sets are replaced with the image copy. As you can see, this procedure is similar to a point-in-time recovery of the table space back to this image copy. This may be acceptable in some cases. But if it is required to have the data as current as possible, you definitely need additional tools, such as IBM Object Restore for DB2. These tools are capable of reading the DB2 log files and generate SQL redo statements to bring the data in your DB2 table to the current state. In the following sections, it is assumed that it is sufficient to restore the accidentally dropped XML table by DSN1COPY with the most recent image copy.

Back to top Characteristics of an XML table space The storage structure for XML is similar to LOB data. There is at least one additional table space (the XML table space) which stores the actual XML documents (exactly one table space per XML column). Depending on the characteristics of the table space containing the base table, DB2 creates the following kinds of the table spaces:

Universal table spaces (UTS), partitioned by growth (PBG) if the base table is placed in a simple or segmented table space or in a partitioned by growth UTS UTS, partitioned by range (PBR) if the base table is placed in a classic partitioned table space or a partitioned by range UTS

In any case, DB2 creates the table space automatically. It is always a UTS and its page size is always 16K. Similar to LOBs, only few alterations of its characteristics are possible, once it is created by DB2. The base table contains an additional column to identify each XML document. It is a BIGINT identity column (GENERATED ALWAYS) named DB2_GENERATED_DOCID_FOR_XML.

In our recovery scenario, a very simple table containing one XML column is restored. It is defined as shown in Listing 1. Listing 1. DDL for XML example objectsCREATE DATABASE XMLTSTDB CCSID UNICODE STOGROUP SYSDEFLT BUFFERPOOL BP1 INDEXBP BP2; CREATE TABLESPACE TS1 IN XMLTSTDB SEGSIZE 64 ; CREATE TABLE XMLTST.TAB1 (ID INTEGER NOT NULL GENERATED BY DEFAULT AS IDENTITY , MESSAGE_ID VARCHAR(80) , XML_FILE XML ) IN XMLTSTDB.TS1 ; CREATE UNIQUE INDEX XMLTST.IX1 ON XMLTST.TAB1 (ID ASC);

DB2 creates the additional XML table space XTAB0000 as partitioned by growth UTS because the base table space is not partitioned. The following information in Listing 2 is from the DB2 Administration Tool that shows a P in column T (Type): Listing 2. DB2 Administration ToolDB2 Admin ------------------ DBT2 Table Spaces --------------- Row 1 to 2 of 2 Command ===> Scroll ===> CSR Commands: GRANT MIG DIS STA STO ALL Line commands: T - Tables D - Database A - Auth G - Storage group ICS - Image copy status DIS - Display table space STA - Start table space STO - Stop table space ? - Show all line commands Select Name DB Name Parts Segsz T L * * * * * * ------ -------- -------- ----------- - TS1 XMLTSTDB 0 64 Y XTAB0000 XMLTSTDB 1 4 P Y ******************************* Bpool * L E S I C Tables * * * * * * Act. pages *

------ - - - - - ------ ----------BP1 A N A N Y 1 1 -1 -1

BP16K0 X N A Y Y END OF DB2 DATA

*******************************

If you do not have DB2 Administration Tool available, you will get the same results with a simple DB2 catalog query, as shown in Listing 3. Listing 3. Catalog Query for XML table spacesSELECT NAME, TYPE, BPOOL, SEGSIZE, PARTITIONS AS PART, MAXPARTITIONS AS MAXPART, LOCKRULE FROM SYSIBM.SYSTABLESPACE WHERE DBNAME='XMLTSTDB' ---------+---------+---------+---------+---------+---------+--------+-----NAME TYPE BPOOL SEGSIZE PART MAXPART LOCKRULE ---------+---------+---------+---------+---------+---------+--------+-----TS1 BP1 64 0 0 A XTAB0000 P BP16K0 4 1 256 X DSNE610I NUMBER OF ROWS DISPLAYED IS 2 DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100

You can also see that DB2 provided a value of 256 for MAXPARTITIONS. XTAB0000 contains the implicitly created table which stores the actual XML data, XTAB1 in our case. SYSIBM.SYSTABLES shows a P in column TYPE to indicate an XML table, as shown in Listing 4. Listing 4. Catalog Query for XML tablesSELECT TSNAME, TYPE, NAME FROM SYSIBM.SYSTABLES WHERE DBNAME='XMLTSTDB' ---------+---------+---------+---------+---------+---------+--------TSNAME TYPE NAME ---------+---------+---------+---------+---------+---------+--------TS1 T TAB1 XTAB0000 P XTAB1 DSNE610I NUMBER OF ROWS DISPLAYED IS 2 DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100

In Listing 5, SYSIBM.SYSINDEXES shows that there are two indexes created implicitly. Listing 5. Catalog Query for XML related indexesSELECT SUBSTR(NAME, 1, 20) AS IXNAME, SUBSTR(CREATOR, 1, 20) AS CREATOR, SUBSTR(TBNAME, 1, 20) AS TBNAME, UNIQUERULE

FROM SYSIBM.SYSINDEXES WHERE DBNAME='XMLTSTDB' ---------+---------+---------+---------+---------+---------+--------IXNAME CREATOR TBNAME UNIQUERULE ---------+---------+---------+---------+---------+---------+--------I_DOCIDTAB1 XMLTST TAB1 X IX1 XMLTST TAB1 U I_NODEIDXTAB1 XMLTST XTAB1 N DSNE610I NUMBER OF ROWS DISPLAYED IS 3

Index IX1 was created on table TAB1 to enforce uniqueness of column ID. Whereas I_NODEIDXTAB1 is used for XML table XTAB1, I_DOCIDTAB1 is defined on the additional column DB2_GENERATED_DOCID_FOR_XML. See this column in the DB2 catalog query shown in Listing 6. It is used internally but, from the recovery perspective, may become important as you will see in a later example. Listing 6. Catalog Query for XML related columnsSELECT COLNO, COLTYPE, NAME FROM SYSIBM.SYSCOLUMNS WHERE TBNAME='TAB1' AND TBCREATOR='XMLTST' ORDER BY COLNO ---------+---------+---------+---------+---------+---------+--------COLNO COLTYPE NAME ---------+---------+---------+---------+---------+---------+--------1 INTEGER ID 2 VARCHAR MESSAGE_ID 3 XML XML_FILE 4 BIGINT DB2_GENERATED_DOCID_FOR_XML DSNE610I NUMBER OF ROWS DISPLAYED IS 4

Be aware that this storage structure requires the XML table space to be included in your backup strategy. There is no implicit image copy of XML table spaces if you run the copy utility on the base table space. You should also ensure a common point of consistency for the base table space and the XML table space if a point in time recovery should be required. As shown in Listing 7, after the objects have been created, an SQL script or program is used to populate the table with XML documents. Image copies with a subsequent QUIESCE are taken to ensure a common point of consistency: Listing 7. Running the copy utility for XML related table spaces//DSNUPROC