Hi, [Juergen Sauer wrote]
> Subject: Re: How to clone the whole db instance from one machine to > other > > > i think that this might the ever coming question but > > being new to > > this world of SAPDB , am eager (also am required) to move > > the db from > > one machine to the another. so can anyone guide me thru the steps. > > There are a few ways to to that. > SapDB -> SapDB > 1) use the "Replication Management" repmcli > First extracting all data: > repmcli -d INSTANCE -u dba,password -E 1 -b datadump.cmd > - ---- datadump.cmd > ---------------------------------------------------------- > TABLEEXTRACT ALL OUTFILE '/tmp/database-ouf.unl' > - > -------------------------------------------------------------- > Second move the /tmp/database-ouf.unl file to the next machine, > where SapDB should run. > You have to insert it there: > repmcli -d INSTANCE -u dba,password -E 1 -b dataload.cmd > - ---- dataload.cmd > ------------------------------------------------------------- > TABLELOAD ALL INFILE '/tmp/database-ouf.unl' OUTFILE > '/tmp/restart.dat' > - > Well, almost right ;-) I would recommend an additional CATALOGEXTRACT/CATALOGLOAD ALL. This assures that all other database objects like views, synonyms, grants, ... will be 'replicated', too. TABLEEXTRACT/TABLELOAD restores only tables and their data. But there is one restriction in using CATALOGEXTRACT/TABLEEXTRACT - CATALOGLOAD/TABLELOAD ALL: when loading the catalog and the data you must run first TABLELOAD and only afterwards CATALOGLOAD. TABLELOAD will create the tables and the indexes and CATALOGLOAD will then create all other objects. The latter command will throw some errors while attempting to create the already existing tables (TABLELOAD!) but this can be ignored. The reason for this kind of processing is that TABLEEXTRACT/TABLELOAD saves an internal (binary) structure of the extracted table that shall be loaded. This structure might contain information that is not longer valid for a newly created table (done with CATALOGLOAD) - the structure might for instance have some information on deleted columns in the source database that do not exists in the target database. Before loading the data RepMan checks the structure of source and target table and if they do not match it stops processing with an error message. Well, and this can be avoided by running TABLELOAD first. I know that this is not state of the art. It will be fixed with the 7.4 release (only with 7.4 because the kernel has to contribute some changes, too). HTH, Steffen -- Steffen Schildberg SAP DB Team SAP Labs Berlin _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
