Strategies for using a mixed restore

To implement a mixed-restore strategy, carefully select the set of dbspaces in which you place your databases and database objects when you create them.

ON-Bar backs up and restores physical, not logical, entities. Thus, ON-Bar cannot restore a particular database or a particular set of tables. Instead, ON-Bar restores a particular set of storage spaces. It is up to you to track what is stored in those storage spaces.

For example, consider a database with the catalogs in the dbspace cat_dbs:

create database mydb in cat_dbs with log;

A table in this database is fragmented among the dbspaces tab_dbs_1 and tab_dbs_2:

create table mytab (i integer, c char(20)) 
fragment by round robin in tab_dbs_1, tab_dbs_2;

An index for the table is stored in the dbspace idx_dbs:

create index myidx on mytab(i) in idx_dbs;

If you need to restore the server, you cannot access all of the data in the example database until you restore the dbspaces containing the database catalogs, table data, and index: in this case, the dbspaces cat_dbs, tab_dbs_1, tab_dbs_2, and idx_dbs.

To simplify the management and tracking of your data, divide your set of dbspaces into subsets in which you store data of a particular urgency. When you create your database objects, place them in dbspaces appropriate to their urgency. For example, if you have data with three levels of urgency, you might want to place all the objects (database catalogs, tables, and indexes) associated with your most urgent data in a particular set of dbspaces: for example, urgent_dbs_1, urgent_dbs_2, ...urgent_dbs_n. You would place all the objects associated with less urgent data in a different set of dbspaces: for example, less_urgent_dbs_1, less_urgent_dbs_2, ... less_urgent_dbs_k. Lastly, you would place your remaining data in a different set of dbspaces: for example, non_urgent_dbs_1, non_urgent_dbs_2, .... non_urgent_dbs_r.

If you need to restore the server, you would first perform a cold restore of all critical dbspaces and dbspaces containing urgent data, urgent_dbs_1 through urgent_dbs_n. For example, assume that logical logs are distributed among two dbspaces, logdbsp_1 and logdbsp_2, and the physical log is in rootdbs. The critical dbspaces are therefore rootdbs, logdbsp_1, and logdbsp_2.

You would perform the initial cold restore by issuing the following ON-Bar command:

onbar -r rootdbs logdbsp_1 logdbsp_2 urgent_dbs_1 ...  urgent_dbs_2

You can bring the server online and all business-urgent data is available.

Next, perform a warm restore for the less-urgent data:

onsmsync
onbar -r less_urgent_dbs_1 less_urgent_dbs_2 .....  less_urgent_dbs_k

Finally, you can perform a warm restore for the rest of the server by issuing the following command.

onbar -r

In a larger system with dozens of dbspaces, you can divide the warm restore portion of the mixed restore into several warm restores, each restoring only a small subset of the dbspaces remaining to be restored in the system.