Re: On recovering single fragmented table via archecker

Hi Omar, I'm wondering if your source table in the schema command file for table-level restore is missing the "with rowids" info. For example, here's the content of my schema command file for restoring a table called frag_tab1 to a file named /tmp/ext_tab1.unl . ===================== -- source table (on archive): create table frag_tab1 ( col1 serial, col2 integer, col3 char(40), col4 boolean, col5 dec ) with rowids fragment by round robin in dbspace1, dbspace2; -- table or file to restore to: create external table ext_tab1 ( col1 serial, col2 integer, col3 char(40), col4 boolean, col5 dec ) using ("/tmp/ext_tab1.unl", delimited); -- restore statement: insert into ext_tab1 select * from frag_tab1; restore to current with no log; ========================= In the source table information, the "with rowids" info says that the table in the backup had been created with the "with rowids" clause for fragmented tables. This information is needed because archecker table-level restore relies on the source table information in the schema command file to understand how to interpret the raw table rows on the backup tapes. A fragmented table created with the "with rowids" clause is formatted differently than a fragmented table created without that clause. Additional note: When you have a fragmented table created without the "with rowids" clause, you can leave off the fragmentation and storage space information for ontape backups, but not for onbar backups. For ontape backups, archecker table-level restore will automatically scan the entire backup for the partitions that belong to the table being restored. However, for onbar backups, since archecker needs to request specific backup objects from the storage manager, archecker will only request those spaces specified in the fragment by clause of the source table(s). Hope this helps. --Hyun-Ju