Visão geral

A exclusão acidental de tabelas ou de espaços de tabela é uma das experiências mais difíceis no trabalho de um administrador de banco de dados. Apesar de a maioria das lojas de TI de grande porte que executam aplicativos de banco de dados importantes terem procedimentos ou ferramentas para lidar com essas situações, ainda há instalações sem o suporte de ferramentas especiais, ou, pior ainda, há pouca experiência ou prática com essas ferramentas.

Este artigo descreve uma situação específica em um ambiente de DB2 para z/OS, no qual o cliente está satisfeito usando os recursos do pureXML do DB2 9 para z/OS e armazenando documentos XML dentro de tabelas XML. Para segurança, as cópias de imagem regulares dos objetos de banco de dados são realizadas no ambiente de produção. Infelizmente, uma dessas tabelas XML foi descartada por um SYSADM de DB2 no ambiente de produção, em vez da tabela com nome idêntico no ambiente de teste.

Não havia ferramentas adicionais como DB2 Log Analysis Tool da IBM para z/OS ou DB2 Object Restore para z/OS instaladas e, por isso, era necessário restaurar o objeto descartado manualmente. Em circunstâncias normais, isso não é uma novidade para um DBA experiente, pois o DB2 para z/OS vem com o programa utilitário DSN1COPY. Mas nesse caso especial, as melhores práticas para o uso do DSN1COPY não poderiam ser aplicadas conforme o esperado. Há algumas coisas a serem consideradas se uma tabela XML precisar ser restaurada com o DSN1COPY.

As seções a seguir descrevem os possíveis desafios da restauração manual de tabelas XML e como lidar com esses desafios. Provavelmente, você não precisará desse procedimento se sua instalação tiver ferramentas de recuperação disponíveis. Porém, mesmo que você tenha ferramentas de recuperação, é útil saber o que torna esse tipo de recuperação tão especial.

Primeiro, veja abaixo uma pequena introdução do programa utilitário DSN1COPY e as características de tabelas XML e de espaços de tabela relacionados.

Pré-requisitos

Para se beneficiar deste artigo, é necessário ter alguma experiência com DSN1COPY e uma compreensão básica dos tipos diferentes de espaços de tabela fornecidos pelo DB2 para z/OS. Para exercitar um cenário de recuperação como esse em seu próprio ambiente de DB2, a Versão 9 ou 10 do DB2 para z/OS deve estar instalada. Talvez sejam necessários também alguns scripts SQL ou programas para criar seus próprios dados XML. Consulte a seção Recursos ao final deste artigo para obter mais informações.

Voltar para parte superior

O programa utilitário DSN1COPY

DBAs experientes de DB2 para z/OS devem estar bastante familiarizados com o programa utilitário DSN1COPY. Ele é enviado como um utilitário off-line com o DB2 e permite a cópia de conjuntos de dados VSAM. Ao usar DSN1COPY, é possível clonar os espaços de tabela e índices do DB2 e substituir os conjuntos de dados VSAM de um objeto DB2 por conjuntos de dados de uma cópia de imagem.

DSN1COPY não verifica se a estrutura dos dados nos conjuntos de dados VSAM é consistente com a definição do objeto DB2 no catálogo. Portanto, é necessário ter cuidado ao usar DSN1COPY para restauração de objetos do DB2. Você também deve considerar as características físicas do espaço de tabela ao codificar o JCL para DSN1COPY.

DSN1COPY é adequado como uma ferramenta para restauração de objetos descartados, pois os procedimentos de recuperação padrão de DB2 não se aplicam nesse caso. Assim que um objeto é descartado, todas as informações sobre as cópias de imagem são removidas do catálogo e diretório do DB2. Portanto, até mesmo o fato de as cópias de imagem ainda existirem não ajuda na recuperação padrão. Os objetos DB2 precisam ser recriados primeiro com DDL de SQL e, em seguida, os dados VSAM subjacentes são substituídos pela cópia da imagem.

Como é possível ver, esse procedimento é parecido com uma recuperação point in time do espaço de tabela de volta para a cópia da imagem. Isso pode ser aceitável em alguns casos. Mas se for necessário ter dados o mais atualizado possível, você definitivamente precisará de ferramentas adicionais, como o IBM Object Restore para DB2. Essas ferramentas são capazes de ler os arquivos de log do DB2 e gerar instruções redo de SQL para levar os dados em sua tabela do DB2 para o estado atual.

Nas seções a seguir, supõe-se que é suficiente restaurar a tabela XML acidentalmente descartada pelo DSN1COPY com a cópia de imagem mais recente.

Voltar para parte superior

Características de um espaço de tabela XML

A estrutura de armazenamento para XML é parecida com os dados de LOB. Há pelo menos um espaço de tabela adicional (o espaço de tabela XML) que armazena os documentos XML reais (exatamente um espaço de tabela pode coluna XML). Dependendo das características do espaço de tabela que contém a tabela base , o DB2 cria os seguintes tipos de espaços de tabela:

• Universal table spaces (UTS), partitioned by growth (PBG) se a tabela base for colocada em um espaço de tabela simples ou segmentado ou em um UTS PBG
• UTS, partitioned by range (PBR) se a tabela base for colocada em um espaço de tabela particionado clássico ou um UTS PBR

Em qualquer caso, o DB2 cria o espaço de tabela automaticamente. É sempre um UTS e o tamanho de sua página é sempre 16K. Parecido com os LOBs, somente algumas alterações de suas características são possíveis após a criação pelo DB2.

A tabela base contém uma coluna adicional para identificar cada documento XML. É uma coluna de identidade BIGINT (GENERATED ALWAYS) chamada DB2_GENERATED_DOCID_FOR_XML.

Em nosso cenário de recuperação, uma tabela muito simples contendo uma coluna XML é restaurada. Ela é definida como mostra a Listagem 1.

CREATE 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);

O DB2 cria o espaço de tabela XML adicional, XTAB0000, como UTS PBG, pois o espaço de tabela base não é particionado.

As seguintes informações na Listagem 2 são da DB2 Administration Tool, que mostra uma P na coluna T (Tipo):

 DB2 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 Bpool  L E S I C Tables  Act. pages  Segsz T L
        *        *             * *      * * * * *      *           *      * * *
 ------ -------- -------- ------ ------ - - - - - ------ ----------- ------ - -
        TS1      XMLTSTDB      0 BP1    A N A N Y      1          -1     64   Y
        XTAB0000 XMLTSTDB      1 BP16K0 X N A Y Y      1          -1      4 P Y
 ******************************* END OF DB2 DATA *******************************

Se você não tiver o DB2 Administration Tool disponível, receberá os mesmos resultados com uma consulta de catálogo de DB2 simples, como mostra a Listagem 3.

SELECT 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

Também é possível ver se o DB2 forneceu um valor de 256 para MAXPARTITIONS.

XTAB0000 contém a tabela criada implicitamente que armazena os dados XML reais, XTAB1 em nosso caso. SYSIBM.SYSTABLES mostra um P na coluna TYPE para indicar uma tabela XML, como mostra a Listagem 4.

SELECT 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

Na Listagem 5, SYSIBM.SYSINDEXES mostra que há dois índices criados implicitamente.

SELECT 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                                          

O índice IX1 foi criado na tabela TAB1 para aplicar a exclusividade do ID da coluna. Enquanto I_NODEIDXTAB1 é usado para a tabela XML XTAB1, I_DOCIDTAB1 é definido na coluna adicional DB2_GENERATED_DOCID_FOR_XML. Veja esta coluna na consulta de catálogo DB2 exibida na Listagem 6. Ela é usada internamente, mas, da perspectiva de recuperação, pode se tornar importante, como mostrado em um exemplo posterior.

SELECT 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

Saiba que essa estrutura de armazenamento exige que o espaço de tabela XML seja incluído em sua estratégia de backup. Não haverá cópia de imagem implícita dos espaços de tabela XML se você executar o utilitário de cópia no espaço de tabela base. Você também deve garantir um ponto comum de consistência para o espaço de tabela base e o espaço de tabela XML, se uma recuperação point in time for necessária.

Como mostra a Listagem 7, após a criação dos objetos, um script SQL ou programa é usado para preencher a tabela com documentos XML. Cópias de imagem com QUIESCE subsequente são realizadas a fim de garantir um ponto comum de consistência:

//DSNUPROC.SYSIN DD *
  LISTDEF LIST1
  INCLUDE TABLESPACES TABLESPACE XMLTSTDB.TS1
  INCLUDE TABLESPACES TABLESPACE XMLTSTDB.XTAB0000

  TEMPLATE TEMPLC UNIT VTS01 DSN &SS..&IC.IC.&DB..&TS..D&DT..T&TI.
  DISP(MOD,CATLG,CATLG) DATACLAS VTS01 RETPD 10  STACK(YES)

  COPY LIST LIST1 COPYDDN(TEMPLC) SHRLEVEL REFERENCE
  QUIESCE LIST LIST1

Essas cópias de imagem serão usadas no seguinte cenário de recuperação.

Voltar para parte superior

Coisas a serem consideradas ao restaurar um espaço de tabela XML com DSN1COPY

Quando a tabela base, TAB1 em nosso exemplo, é descartada, a tabela XML correspondente e seu espaço de tabela são descartados também. Isso é diferente dos espaços de tabela LOB. Os espaços de tabela LOB criados com CURRENT RULES='DB2' ainda existirão mesmo se a base e sua tabela auxiliar correspondente forem descartadas.

A partir de uma perspectiva do DB2, o espaço de tabela TS1 ainda parece recuperável, pois o espaço de tabela não foi descartado. No entanto, uma recuperação padrão de DB2 não funcionaria para o espaço de tabela XML, pois todas as informações de recuperação no catálogo e diretório DB2 são perdidas. Portanto, os objetos, a tabela base e XML, precisam ser recuperados usando DSN1COPY.

Para a tabela base, esse é o processo normal. Para a tabela XML, algumas armadilhas podem ocorrer.

A primeira etapa é a recriação dos objetos com o script SQL exibido anteriormente na Listagem 1. Para executar o DSN1COPY apropriadamente, é necessário especificar os identificadores de objeto para o banco de dados, espaço de tabela (configuração de página) e tabelas. DSN1COPY permite a tradução de IDs de objeto armazenados na cópia da imagem para IDs de objeto dos objetos recém-criados. Os IDs de objeto de destino para os objetos recém-criados podem ser facilmente recuperados do catálogo DB2, como mostra a Listagem 8.

SELECT DBID, PSID, NAME FROM SYSIBM.SYSTABLESPACE
WHERE DBNAME='XMLTSTDB';
---------+---------+---------+---------+---------+---------+-
  DBID    PSID  NAME
---------+---------+---------+---------+---------+---------+-
   393       2  TS1
   393       5  XTAB0000
DSNE610I NUMBER OF ROWS DISPLAYED IS 2
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+-
SELECT OBID, NAME FROM SYSIBM.SYSTABLES
WHERE DBNAME='XMLTSTDB';
---------+---------+---------+---------+---------+---------+-
  OBID  NAME
---------+---------+---------+---------+---------+---------+-
     3  TAB1                
     6  XTAB1

Para o espaço de tabela base TS1 e sua tabela TAB1, o catálogo DB2 indica DBID 393, PSID 2 e OBID 3. O espaço de tabela XML tem o mesmo DBID, mas PSID (5) e OBID(6) diferentes.

Os IDs de objeto correspondentes para as tabelas descartadas não estão mais disponíveis no catálogo DB2. Eles precisam ser extraídos do próprio conjunto de dados de imagem. Podemos usar o programa utilitário DSN1PRNT para isso.

Voltar para parte superior

Obtendo os IDs de objeto corretos

O Guia de Administração do DB2 (consulte a seção Recursos deste artigo) fornece instruções detalhadas sobre como usar DSN1PRNT para extrair IDs de objeto das cópias de imagem. Como mostra a Listagem 9, para a tabela base, DSN1PRNT é chamado com o conjunto de dados da cópia da imagem como dados para SYSUT1:

//PRT   EXEC PGM=DSN1PRNT,
//           PARM='PAGESIZE(4K),FULLCOPY,FORMAT,NODATA'
//STEPLIB  DD DSN=DB2.DBT2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=DBT2.FIC.XMLTSTDB.TS1.D2011209.T145537,
//         DISP=SHR

Lembre-se de especificar o PAGESIZE correto para a tabela base (4K em nosso caso). Como mostra a Listagem 10, DBID e PSID podem ser localizados no campo HPGOBID na página de cabeçalho da tabela base.

PAGE: # 00000000 -------------------------------------------------------
HEADER PAGE:  PGCOMB='10'X  PGLOGRBA='032269910A04'X  PGNUM='00000000'X
              HPGOBID='01890002'X  HPGHPREF='000000B4'X  HPGCATRL='00'X

Em nosso caso, DBID é X'0189' (ou 393 em decimal) e PSID é X'0002' (2 em decimal). TAB1s OBID está localizado nas páginas de dados (campo PGSOBD), como mostra a Listagem 11.

  PGSLTH='0064'X  PGSOBD='0003'X  PGSBID='01'X
  PGSLTH='0064'X  PGSOBD='0003'X  PGSBID='02'X
  PGSLTH='0064'X  PGSOBD='0003'X  PGSBID='03'X
  PGSLTH='0064'X  PGSOBD='0003'X  PGSBID='04'X

Há quatro registros para OBID = X'0003' em nosso exemplo.

Observação: este exemplo mostra um espaço de tabela segmentado. Use o campo HPGROID na página de cabeçalho em vez de PGSOBD, se sua tabela base estiver armazenada em um UTS.

Para espaços de tabela XML há um procedimento um pouco diferente. É necessário especificar PAGESIZE(16K) para espaços de tabela XML. Não há outra opção. Outros parâmetros não são afetados. Use o nome do conjunto de dados da cópia da imagem como um conjunto de dados de entrada, como mostra a Listagem 12.

//PRT   EXEC PGM=DSN1PRNT,
//           PARM='PAGESIZE(16K),FULLCOPY,FORMAT,NODATA'
//STEPLIB  DD DSN=DB2.DBT2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=DBT2.FIC.XMLTSTDB.XTAB0000.D2011209.T145537,
//         DISP=SHR

Não especifique LOB como um parâmetro para DSN1PRNT. Embora existam semelhanças entre os espaços de tabela XML e LOB, isso não funciona para espaços de tabela XML.

DBID e PSID podem ser extraídos da mesma forma que a tabela base (campo HPGOBID na página de cabeçalho). O OBID da tabela XML também está localizado na página de cabeçalho. Como mostra a Listagem 13, é possível ver no campo HPGROID, há o OBID no formato hexadecimal.

HEADER PAGE:  PGCOMB='10'X  PGLOGRBA='03226993AD31'X  PGNUM='00000000'X  PGFLAGS='38'X
              HPGOBID='01890005'X  HPGHPREF='0000002D'X  HPGCATRL='00'X
              HPGCATV='00'X  HPGTORBA='000000000000'X  HPGTSTMP='201107281651195
              HPGSSNM='DBT2'  HPGFOID='0004'X  HPGPGSZ='4000'X  HPGSGSZ='0004'X
              HPGZ3PNO='000000'X  HPGZNUMP='00'X  HPGTBLC='0001'X  HPGROID='0006'
              ...

Neste exemplo, esse é X'0189' (393) para DBID, X'0005' (5) para PSID e X'0006' (6) para OBID. Não se preocupe se você não encontrar uma dica na documentação do DB2 para espaços de tabela XML em conjunto com DSN1PRNT. As mesmas regras para os espaços de tabela LOB se aplicam nesse caso.

Agora, todas as informações necessárias devem ser usadas para executar o utilitário DSN1COPY.

O exemplo exibido na Tabela 1 mostra que não é necessário permitir que o DSN1COPY mude os IDs de objeto durante o processo de cópia se os IDs de destino e de origem forem idênticos.

Voltar para parte superior

O processo de cópia

O processo de cópia é realizado usando o DSN1COPY. Ele precisa ser executado duas vezes, uma cópia para a base e a segunda para o espaço de tabela XML. Não há considerações especiais para o espaço de tabela base. Especifique o PAGESIZE correto e (se for necessário) o valor correto para NUMPARTS. Não se esqueça de que a cópia é realizada a partir de uma cópia da imagem, como mostra a Listagem 14.

//RE1   EXEC PGM=DSN1COPY,PARM='PAGESIZE(4K),FULLCOPY,OBIDXLAT,RESET'
//STEPLIB  DD DSN=DB2.DBT2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=DBT2.FIC.XMLTSTDB.TS1.D2011209.T145537,
//         DISP=SHR
//SYSUT2   DD DSN=DBT2.DSNDBC.XMLTSTDB.TS1.I0001.A001,
//         DISP=SHR
//SYSXLAT  DD *
 393,393
 2,2
 3,3

O espaço de tabela XML exige atenção especial. Como mostra a Listagem 15, para DSN1PRNT, um PAGESIZE(16K) precisa ser especificado para XML. Observe que não há parâmetro especial para indicar que um espaço de tabela XML deve ser copiado.

			

//RE1   EXEC PGM=DSN1COPY,
//           PARM='PAGESIZE(16K),FULLCOPY,OBIDXLAT,RESET'
//STEPLIB  DD DSN=DB2.DBT2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=DBT2.FIC.XMLTSTDB.XTAB0000.D2011209.T145537,
//         DISP=SHR
//SYSUT2   DD DSN=DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A001,
//         DISP=OLD
//SYSXLAT  DD *
 393,393
 5,5
 6,6

Não se esqueça das reconstruções do índice. Elas são necessárias para ambos os espaços de tabela, pois há o índice DOCID na tabela base e o índice NODEID adicional na tabela XML. Esse exemplo parece bastante simples. Talvez você pense que não há necessidade de atenção especial para os espaços de tabela XML, mas os exemplos a seguir mostrarão que ainda há alguns problemas para considerar.

Voltar para parte superior

Como lidar com diversas partições de um espaço de tabela XML

Como já foi mencionado, se a tabela base não for particionada, o DB2 criará um espaço de tabela PBG para a tabela XML. Assim que uma partição fica cheia, o DB2 adiciona outra partição ao espaço de tabela. Todas as partições precisam ser respeitadas em procedimentos de backup e recuperação.

Se você armazenar documentos XML maiores, provavelmente o espaço de tabela XML crescerá para duas ou mais partições. A tabela base pode permanecer muito pequena e ocupar somente alguns megabytes de dados, enquanto o espaço de tabela XML pode ocupar várias partições.

O número real de partições é refletido na coluna PARTITIONS em SYSIBM.SYSTABLESPACE. Também é possível ver conjuntos de dados VSAM adicionais no utilitário de lista de conjuntos de dados ISPF.

Neste caso de teste, 477 linhas foram inseridas na tabela XMLTST.TAB1. 418 delas tinham documentos XML. Esses arquivos ocupavam cercam de 5 GB de espaço e, portanto, o DB2 criou uma segunda partição para o espaço de tabela XML. É possível verificar isso com o utilitário de lista de conjuntos de dados (ISPF opção 3.4), como mostra a Listagem 16.

			
DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A001                       *VSAM*
DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A002                       *VSAM*
DBT2.DSNDBD.XMLTSTDB.XTAB0000.I0001.A001                       D29003+
DBT2.DSNDBD.XMLTSTDB.XTAB0000.I0001.A002                       D29125

Uma cópia da imagem completa do espaço de tabela XML criará um conjunto de dados da cópia da imagem contendo os dados para as partições 1 e 2.

O que acontecerá se ocorrer um acidente e o espaço de tabela base TS1 for descartado? Felizmente, foram feitas cópias da imagem que podem ser usadas como dados para o DSN1COPY, como mostrou o último exemplo. Depois de verificar os IDs de objeto e analisar os conjuntos de dados da cópia da imagem com o DSN1PRNT, o DSN1COPY será executado para ambos os espaços de tabela.

A cópia do espaço de tabela base deve terminar sem erros, mas para o espaço de tabela XML XTAB0000, a cópia termina com RC=08 e a seguinte mensagem de erro, como mostra a Listagem 17.

				
DSN1989I DSN1COPY IS PROCESSED WITH THE FOLLOWING OPTIONS:
         NO CHECK/NO PRINT/16K/FULLCOPY    /NON-SEGMENT/NUMPARTS=   0/   OBIDXLAT
          DSSIZE=   /PIECESIZ=    /       /
DSN1998I INPUT  DSNAME = DBT2.FIC.XMLTSTDB.XTAB0000.D2011210.T154845 , SEQ
DSN1997I OUTPUT DSNAME = DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A001    , VSAM
DSN1992I VSAM PUT ERROR, RPLERREG = 008, RPLERRCD =  028

DSN1993I DSN1COPY TERMINATED,  00102196 PAGES PROCESSED

O APAR informativo da IBM II13617 dá uma ideia do que está acontecendo nesse caso. DSN1COPY não pode lidar com um objeto com mais de 4GB. Em vez disso, recomenda-se usar os conjuntos de dados extended attribute (EA). II13617 e o Guia do utilitário DB2 fornecem uma descrição detalhada de uma solução se os conjuntos de dados EA não puderem ser alocados.

Como mostra a Listagem 18, também é uma dica útil, pois indica que pelo menos uma segunda partição do PBG é necessária. Portanto, é necessário alocar manualmente o conjunto de dados para a segunda partição.

			

//IDCAMS EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
 DEFINE CLUSTER -
   (NAME('DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A002') -
    LINEAR -
    REUSE -
    SHAREOPTIONS(3 3)  -
    RECORDS(1000 1000) -
    VOLUMES(D29125)) -
  DATA -                                    
   (NAME('DBT2.DSNDBD.XMLTSTDB.XTAB0000.I0001.A002'));

Também é importante especificar NUMPARTS(2) para DSN1COPY a fim de indicar se o conjunto de dados da cópia da imagem cobre duas partições. Você estará no caminho certo se DSN1COPY retornar mensagens, como mostra a Listagem 19.

			
DSN1989I DSN1COPY IS PROCESSED WITH THE FOLLOWING OPTIONS:
         NO CHECK/NO PRINT/16K/FULLCOPY    /NON-SEGMENT/NUMPARTS=0002/   OBIDXLAT
          DSSIZE=   /PIECESIZ=    /       /
DSN1998I INPUT  DSNAME = DBT2.FIC.XMLTSTDB.XTAB0000.D2011210.T154845 , SEQ
DSN1997I OUTPUT DSNAME = DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A001    , VSAM
DSN1997I OUTPUT DSNAME = DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A002    , VSAM

DSN1994I DSN1COPY COMPLETED SUCCESSFULLY,  00369789 PAGES PROCESSED

Se NUMPARTS(2) não for especificado, você confundirá o DSN1COPY, pois ele não espera dados para mais de uma partição no conjunto de dados da cópia da imagem. Você receberá o seguinte resultado, exibido na Listagem 20.

				
DSN1989I DSN1COPY IS PROCESSED WITH THE FOLLOWING OPTIONS:
         NO CHECK/NO PRINT/16K/FULLCOPY    /NON-SEGMENT/NUMPARTS=   0/   OBIDXLAT
          DSSIZE=   /PIECESIZ=    /       /
DSN1998I INPUT  DSNAME = DBT2.FIC.XMLTSTDB.XTAB0000.D2011210.T154845 , SEQ
DSN1997I OUTPUT DSNAME = DBT2.DSNDBC.XMLTSTDB.XTAB0000.I0001.A001    , VSAM
DSN1961I - PIECE NUMBER 0002 IS INVALID.                     
                                                                                
DSN1993I DSN1COPY TERMINATED,  00262080 PAGES PROCESSED

Compare o número de páginas da execução bem-sucedida com o número de páginas da última execução. Parece que faltam cerca de 100.000 páginas. Elas estão armazenadas na segunda partição.

Agora é possível executar REBUILD INDEX para os dois espaços de tabela e tudo parece correto. Mas ainda há um grande problema restando. Para DB2, o espaço de tabela XML é um espaço PBG com apenas uma partição. No DB2 Versão 9 para z/OS há uma opção ao criar um espaço de tabela PBG para forçar o DB2 a criar duas ou mais partições. O fato de uma segunda partição ter sido criada manualmente e preenchida com DSN1COPY não é suficiente. O DB2 reconhece apenas as linhas na primeira partição. É possível verificar isso executando o utilitário CHECK DATA no espaço de tabela base. CHECK DATA informa inconsistências entre o espaço de tabela base e XML. Consulte o seguinte relatório exibido na Listagem 21 como exemplo:

				
DSNU050I    210 21:20:24.31 DSNUGUTC -  CHECK DATA table space XMLTSTDB.TS1 SCOPE ALL
LOBERROR REPORT
DSNU730I    210 21:20:24.42 DSNUKDST - CHECKING TABLE XMLTST.TAB1
DSNU3340I   210 21:20:24.44 DSNUGSOR - UTILITY PERFORMS DYNAMIC ALLOCATION OF SORT
DSNU042I    210 21:20:24.57 DSNUGSOR - SORT PHASE STATISTICS -
                      NUMBER OF RECORDS=477
                      ELAPSED TIME=00:00:00
DSNU3340I   210 21:20:24.75 DSNUGSOR - UTILITY PERFORMS DYNAMIC ALLOCATION OF SORT
DSNU042I    210 21:20:24.87 DSNUGSOR - SORT PHASE STATISTICS -
                      NUMBER OF RECORDS=166
                      ELAPSED TIME=00:00:00
DSNU822I    210 21:20:24.88 DSNUKERK - XML COLUMN XML_FILE IN TABLE XMLTST.TAB1
                        MISSING IN INDEX XMLTST.I_NODEIDXTAB1. 
                        DOCID X'008000000000000127'
DSNU822I    210 21:20:24.88 DSNUKERK - XML COLUMN XML_FILE IN TABLE XMLTST.TAB1
                        MISSING IN INDEX XMLTST.I_NODEIDXTAB1. 
                        DOCID X'008000000000000128'
...

Portanto, o próximo desafio seria encontrar uma forma de permitir que o DB2 espalhasse os dados XML em mais de uma partição. Uma forma de conseguir isso é reorganizar o espaço de tabela XML de uma maneira que o DB2 alocasse uma segunda partição para os conjuntos de dados sombra. Antes da REORG, o DBA aumentaria consideravelmente o PCTFREE (aqui, de 5 para 25) ou o FREEPAGE. Neste exemplo, a REORG do DB2 respeitou o valor aumentado para PCTFREE e alocou uma partição, como era pretendido.

Observação: DSN1COPY e REBUILD INDEX para o espaço de tabela XML precisam ser executados mais uma vez. A REORG anterior interferiu somente nos dados da primeira partição. Os dados armazenados no segundo cluster VSAM não estavam visíveis para DB2.

Agora, o DB2 fica ciente da segunda partição. CHECK DATA deve ser executado com êxito e os documentos XML devem ser restaurados completamente.

Aviso importante: esse é um exemplo de um ambiente executando a versão 9 do DB2 para z/OS. A versão 10 permite a adição de novas partições aos espaços de tabela PBG. Portanto, é muito mais fácil criar o número correto de partições antes de executar o DSN1COPY.

Voltar para parte superior

Observe a ordem correta de colunas para a tabela base

A estrutura interna da tabela base pode causar outro problema para o processo de recuperação.

Lembre-se: o DB2 cria colunas de DOCID internas com o tipo de dados BIGINT (DB2_GENERATED_DOCID_FOR_XML) na tabela base a fim de armazenar uma referência à linha correspondente no espaço de tabela XML. Isso é parecido com tabelas com colunas LOB, em que o DB2 cria colunas ROWID na tabela base (DB2_GENERATED_ROWID_FOR_LOBS).

Quando a tabela XML ou LOB é criada ou a coluna XML ou LOB é adicionada com uma instrução ALTER TABLE ADD COLUMN , essas colunas DOCID são sempre colocadas na última coluna da tabela. Não é relevante em qual posição em sua DDL o XML ou LOB aparece. Se você adicionar mais colunas à sua tabela XML ou LOB, a coluna DOCID permanecerá nessa posição. Para o próximo exemplo, outras duas colunas são adicionadas à tabela TAB1.

Lembre-se do DDL1 para TAB1 exibido anteriormente na Listagem 1. Uma tabela base com quatro colunas é criada, como mostra a Tabela 2.

Outras duas colunas são adicionadas:

				
ALTER TABLE XMLTST.TAB1 ADD CREATED_TS TIMESTAMP ;
ALTER TABLE XMLTST.TAB1 ADD STATUS_CODE CHAR(1) NOT NULL WITH DEFAULT;

A estrutura interna da tabela reflete essas mudanças, como mostra a Tabela 3.

Agora a tabela é descartada e recriada. Talvez, o DBA ou o desenvolvedor de aplicativo ainda tenha o DDL disponível, refletindo as mudanças aplicadas com ALTER TABLE posteriormente, como mostra a Listagem 22.

CREATE TABLE XMLTST.TAB1
(ID INTEGER NOT NULL GENERATED BY DEFAULT AS IDENTITY ,
 MESSAGE_ID VARCHAR(80) ,
 XML_FILE XML,
 CREATED_TS TIMESTAMP,
 STATUS_CODE CHAR(1) NOT NULL DEFAULT  )
 IN XMLTSTDB.TS1 ;

Isso parece bom e, do ponto de vista do aplicativo, a ordem de colunas parece idêntica à tabela descartada. A estrutura interna indica quais tipos de problemas são implicados, como mostra a Tabela 4.

O DOCID é colocado na posição 6, logo depois da última coluna de dados visível . Isso não tem influência sobre os trabalhos de DSN1COPY, mas a execução de REBUILD INDEX(ALL) no espaço de tabela TS1 falha, como mostra a Listagem 23.

		
DSNI014I  -DBT2 DSNIMOFR DATA IN USE DURING ABEND 552
           REASON 00C90101
           ERQUAL 53A2
           TYPE 00000302
           NAME XMLTSTDB.TS1     .X'00000002'
           CONNECTION-ID=UTILITY
           CORRELATION-ID=...
           LUW-ID=...
DSNI014I  -DBT2 DSNIMOFR DATA IN USE DURING ABEND 553
           REASON 00C90101
           ERQUAL 53A2
           TYPE 00000302
           NAME XMLTSTDB.TS1     .X'00000001'
           CONNECTION-ID=UTILITY                             
           CORRELATION-ID=...
           LUW-ID=...

Supõe-se que os DSN1COPYs foram codificados corretamente, especialmente as traduções do ID do objeto correto foram especificadas. Mas é preciso que a ordem de colunas na tabela recriada seja idêntica à ordem de colunas na cópia da imagem. Lembre-se de criar a nova tabela da mesma maneira que a antiga. As colunas adicionadas após a criação original da tabela precisam ser adicionadas com ALTER TABLE e não devem ser especificadas na instrução CREATE TABLE .

Essa regra não se aplica apenas às tabelas base que contêm as colunas XML. Você receberá mensagens de erro parecidas quando não prestar atenção na ordem exata de colunas para outros tipos de tabelas. Mas você não pode dizer explicitamente ao DB2 onde colocar as colunas DOCID internas para as tabelas base contendo colunas XML, e tabelas base contendo colunas LOB também.

Aviso importante: o cenário supõe que o histórico de mudanças exato da tabela seja conhecido. Porém, mesmo se o histórico de mudanças não estiver disponível, ou seja, você conhecer a DDL, mas não tiver certeza de quais colunas foram adicionadas posteriormente, você não estará perdido. É possível usar um método de tentativa e erro (criar a tabela, adicionar colunas, executar o DSN1COPY e ver se funciona) ou um método mais sofisticado. Crie cópias de imagem regulares de suas tabelas de catálogo DB2. Basta usar a última cópia do espaço de tabela SYSDBASE de DSNDB06, descarregá-lo e carregá-lo em uma cópia de DSNDB06. Consulte a coluna CREATEDTS em SYSCOLUMNS e você saberá quais colunas não devem ser incluídas na instrução CREATE TABLE .

Em nosso exemplo, SYSTABLES e SYSCOLUMNS indicam claramente que as colunas CREATED_TS e STATUS_CODE foram adicionadas em uma etapa separada, como mostra a Listagem 24.

SELECT TB.CREATEDTS AS TAB_CREATED, COL.CREATEDTS AS COL_CREATED,
COL.NAME
FROM SYSIBM.SYSTABLES TB
JOIN SYSIBM.SYSCOLUMNS COL
ON TB.NAME = COL.TBNAME AND TB.CREATOR=COL.TBCREATOR
AND TB.CREATOR='XMLTST' AND TB.NAME='TAB1';
---------+---------+---------+---------+---------+---------+---------+---------+
TAB_CREATED                 COL_CREATED                 NAME
---------+---------+---------+---------+---------+---------+---------+---------+
2011-08-01-14.37.33.286314  2011-08-01-14.37.33.286314  ID
2011-08-01-14.37.33.286314  2011-08-01-14.37.33.286314  MESSAGE_ID
2011-08-01-14.37.33.286314  2011-08-01-14.37.33.286314  XML_FILE           
2011-08-01-14.37.33.286314  2011-08-01-14.37.33.286314  DB2_GENERATED_DOCID_FOR_XML
2011-08-01-14.37.33.286314  2011-08-01-14.37.43.729698  CREATED_TS
2011-08-01-14.37.33.286314  2011-08-01-14.37.45.246738  STATUS_CODE
DSNE610I NUMBER OF ROWS DISPLAYED IS 6
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100

Voltar para parte superior

Como lidar com SQLCODE -803 após a restauração do espaço de tabela XML

Ainda há um possível problema após a restauração bem-sucedida do espaço de tabela XML. Mesmo se todos os documentos XML forem recuperados e puderem ser selecionados com instruções SQL, será possível encontrar o próximo e, assim espera-se, último problema se tentar inserir novos documentos XML na tabela.

Em nosso exemplo, a tabela TS1 tem uma coluna de identidade (ID) que é declarada como gerada por padrão. é necessário considerar que o contador interno para essa coluna de identidade ainda é 0 após a recriação da tabela, a menos que um valor de início seja explicitamente especificado. Portanto, é necessário tomar cuidado ao ajustar esse contador com um valor superior ao valor máximo nos dados.

Supondo que os dados restaurados contêm 34 linhas, a seguinte DDL deve ser executada antes de inserir novas linhas:

ALTER TABLE XMLTST.TAB1 ALTER COLUMN ID RESTART WITH 35;

Essa é uma técnica usual quando uma coluna de identidade definida pelo usuário é envolvida. Também é aplicável se a coluna tiver sido definida com generated always. No entanto, a inserção de um novo documento XML ainda falha com um SQLCODE -803, como mostra a Listagem 25.

---------+---------+---------+---------+---------+---------+---------+---------+
INSERT INTO XMLTST.TAB1 (MESSAGE_ID, XML_FILE, STATUS_CODE)
SELECT MESSAGE_ID, XML_FILE, 'A' FROM MYSCHEMA.TAB1 WHERE ID=40 ;
---------+---------+---------+---------+---------+---------+---------+---------+
DSNT408I SQLCODE = -803, ERROR:  AN INSERTED OR UPDATED VALUE IS INVALID
         BECAUSE INDEX IN INDEX SPACE IRDO1IH8 CONSTRAINS COLUMNS OF THE TABLE
         SO NO TWO ROWS CAN CONTAIN DUPLICATE VALUES IN THOSE COLUMNS. 
         RID OF EXISTING ROW IS X'0000000201'. 
DSNT418I SQLSTATE   = 23505 SQLSTATE RETURN CODE
DSNT415I SQLERRP    = DSNXRUID SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD    = -150 13172739  0  13817814  -490143744  0 SQL DIAGNOSTIC
         INFORMATION
DSNT416I SQLERRD    = X'FFFFFF6A'  X'00C90003'  X'00000000'  X'00D2D7D6'
         X'E2C90000'  X'00000000' SQL DIAGNOSTIC INFORMATION
---------+---------+---------+---------+---------+---------+---------+---------+

Uma análise rápida no catálogo DB2 mostra que o índice exclusivo na coluna DB2_GENERATED_DOCID_FOR_XML (the DOCID) foi violado nesse caso. Lembre-se de que o DB2 mantém um DOCID exclusivo na tabela base para cada documento XML. Esse DOCID é declarado como BIGINT GENERATED ALWAYS AS IDENTITY. Seu contador interno é 0 após a criação da tabela. A primeira inserção tenta criar o DOCID #1, mas falha como se ele já estivesse atribuído a um documento. É possível verificar isso selecionando DB2_GENERATED_DOCID_FOR_XML na tabela base.

Portanto, a DDL usual é executada a fim de ajustar o contador dessa coluna de identidade, como mostra a Listagem 26.

ALTER TABLE XMLTST.TAB1 ALTER COLUMN DB2_GENERATED_DOCID_FOR_XML
RESTART WITH 35;
---------+---------+---------+---------+---------+---------+---------+---------+
DSNT408I SQLCODE = -350, ERROR:  DB2_GENERATED_DOCID_FOR_XML WAS IMPLICITLY OR
         EXPLICITLY REFERENCED IN A CONTEXT IN WHICH IT CANNOT BE USED
DSNT418I SQLSTATE   = 42962 SQLSTATE RETURN CODE
DSNT415I SQLERRP    = DSNXIALC SQL PROCEDURE DETECTING ERROR
DSNT416I SQLERRD    = 133 0  0  -1  0  0 SQL DIAGNOSTIC INFORMATION
DSNT416I SQLERRD    = X'00000085'  X'00000000'  X'00000000'  X'FFFFFFFF'
         X'00000000'  X'00000000' SQL DIAGNOSTIC INFORMATION

O SQLCODE indica que essa coluna não pode ser alterada pelo usuário, pois seus valores são mantidos pelo DB2. Portanto, não é uma opção solucionar esse problema com instruções ALTER . É necessário repetir as inserções até que a linha possa ser inserida com êxito. Nesse caso (34 linhas na tabela), é necessário realizar isso 34 vezes. Cada instrução de inserção, independentemente se for bem-sucedida ou não, aumenta o contador interno para DOCID no catálogo DB2. Portanto, a 35º inserção terá êxito neste exemplo.

Não é muito trabalhoso executar essas instruções para essa quantidade pequena de dados, mas pode demorar um pouco se milhares ou milhões de documentos XML estiverem envolvidos.

Aviso importante:o DB2 10 fornecerá a possibilidade de gerar o DOCID em ordem aleatória. Isso exige a aplicação do PTF para APAR PM31487 , assim que estiver disponível, e a definição do novo ZPARM XML_RANDOMIZE_DOCID como YES.

Voltar para parte superior

Lista de verificação para uma restauração bem-sucedida

Como indica o último capítulo, há vários problemas a serem considerados quando as tabelas XML são envolvidas em uma recuperação de uma tabela descartada. Se você não tiver ferramentas que facilitem a recuperação de objetos descartados, será necessário ter ainda mais cuidado. Faça o seguinte:

• Faça cópias de imagem frequentes de suas tabelas que contêm as colunas XML. Não se esqueça dos espaços de tabela XML correspondentes e tente manter ambas as cópias de imagem (para o espaço de tabela base e XML) consistentes.
• Defina seus objetos WITH RESTRICT ON DROP
• Faça cópias de imagem frequentes de seu catálogo DB2. Isso pode ser bastante útil na coleta das seguintes informações:
  • Quais eram os IDs de objeto dos objetos descartados?
  • Quantas partições provavelmente tinha um espaço de tabela XML PBG?
  • Qual era o histórico de mudanças da tabela, por exemplo, quais colunas foram adicionadas após a criação inicial da tabela?

Veja a lista de verificação abaixo quando estiver em uma situação de restauração de uma tabela XML a partir de uma cópia.

• Identifique quais conjuntos de dados de cópia da imagem serão os dados para o processo de cópia.
• Recrie a DDL da tabela descartada e separe as colunas adicionadas após a criação inicial da tabela.
• Recrie o espaço de tabela, a tabela base e os índices. O DB2 criará o espaço de tabela XML, a tabela XML e índices DOCID- e NODEID.
• Determine os IDs de objeto dos espaços de tabela base e XML e as tabelas para os objetos descartados e recriados.
• Execute o DSN1COPY para o espaço de tabela base e o espaço de tabela XML (PAGESIZE 16K).
• Recrie todos os índices para o espaço de tabela base e XML.
• Se houver a necessidade de mais partições para o espaço de tabela XML, faça o seguinte:
  • Defina as partições manualmente
  • Execute novamente o DSN1COPY com a opção NUMPARTS correta
  • Reorganize o espaço de tabela base (e XML implícito) de modo que o DB2 fique ciente das partições adicionais
  • Execute o DSN1COPY para o espaço de tabela XML mais uma vez
  • Recrie os índices no espaço de tabela XML mais uma vez
• Execute CHECK DATA no espaço de tabela base para garantir que a tabela base e XML estejam consistentes.
• Selecione MAX(DB2_GENERATED_DOCID_FOR_XML) na tabela base e execute inserções simuladas para incrementar o contador DOCID interno.
• Se for necessário, ajuste os valores de outras colunas de identidade.

Aviso importante: não use DSN1COPY para transferir objetos XML a outros subsistemas DB2 (como é basicamente possível para objetos que não são XML).

Voltar para parte superior

Conclusão

Este artigo mostra uma situação que, esperamos, não ocorra com muita frequência em ambientes reais de DB2. Mas quando um evento como esse ocorre, pode se tornar muito crítico. Normalmente, há procedimentos de recuperação padrão, e os administradores têm experiência suficiente para praticar o utilitário de recuperação do DB2 e conhecem suas implicações.

A recuperação de descarte é mais crítica. Ela raramente ocorre e às vezes não há procedimentos padrão para lidar com ela.

Este artigo deve criar a consciência necessária para os administradores para o tipo especial de espaços de tabela XML. Ele deve incentivar os DBAs a estabelecerem e praticarem procedimentos para a recuperação de descarte que cobrem não apenas XML, mas também espaços de tabela padrão e LOB. Isso também se aplica se você depender de ferramentas de banco de dados para recuperação de objeto. Essas ferramentas tornam a vida de um DBA mais conveniente e fornecem mais suporte em situações críticas. Se você depende ou não de ferramentas, este artigo forneceu um conhecimento útil.

Recursos

Aprender

• Explore o seguinte white paper no developerWorks para obter uma visão abrangente do pureXML no DB2 para z/OS.
  
  
• Leia a nova publicação do IBM Redbooks sobre XML para DB2 z/OS, que cobre muitos aspectos de pureXML no mainframe. Ela foi escrita para desenvolvedores de aplicativo em z/OS, mas também para administradores de DB2.
  
  
• Obtenha os recursos necessários na área de Information Management no developerWorks, para melhorar suas habilidades em uma grande variedade de produtos do IBM Information Management.
  
  
• Saiba mais sobre Information Management na zona de Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
  
  
• Siga o DeveloperWorks no Twitter.
  
  
• Acompanhe as Demos on demand do developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidade avançada para desenvolvedores experientes.
  
  

Obter produtos e tecnologias

• Confira o APAR informativo da IBM II13617 sobre como lidar com conjuntos de dados EA para DB2.
  
  
• Consulte o APAR da IBM PM31487 sobre DOCIDs aleatórios para documentos XML no DB2 para z/OS.
  
  
• Seu ponto de partida para a documentação atual do produto para DB2 z/OS é o Centro de Informações do DB2 na Web. Para recuperação de objetos DB2, consulte o capítulo sobre operação e recuperação. Pesquise também por DSN1COPY e obtenha mais informações nos guias de utilitários.
  
  
• Crie seu próximo projeto de desenvolvimento com software de avaliação da IBM, disponível para download diretamente no developerWorks, ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira os blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre o autor

Christoph Theisen é IT Specialist e Administrador de banco de dados certificado pela IBM para DB2 9 no z/OS. Ele trabalha para o IBM Software Group Services na Alemanha e tem duas décadas de experiência em projetos de desenvolvimento de aplicativo, internamente na IBM e para clientes da IBM. Seu foco principal é modelagem de dados e implementação de modelos de dados, especialmente para DB2 para z/OS. Além de desenvolvimento de aplicativo, Christoph também trabalhou com DB2 para tópicos relacionados ao sistema z/OS nos últimos anos.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Visão geral
• O programa utilitário DSN1COPY
• Características de um espaço de tabela XML
• Coisas a serem consideradas ao restaurar um espaço de tabela XML com DSN1COPY
• Obtendo os IDs de objeto corretos
• O processo de cópia
• Como lidar com diversas partições de um espaço de tabela XML
• Observe a ordem correta de colunas para a tabela base
• Como lidar com SQLCODE -803 após a restauração do espaço de tabela XML
• Lista de verificação para uma restauração bem-sucedida
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais