What a comprehensive and great answer!
Thank you very much :)
On Mi�vikudagur, December 4, 2002, at 11:02 AM, Schildberg, Steffen wrote:
Hi Eirikur, [Eirikur S.Hrafnsson wrote]after reading about the replication manager I'm just as far away from knowing how to export a schema (user) from a sapdb database on a (linux) machine to another sapdb database on another (linux) machine.How come ;-)? We'll improve the docs as already promised.Ok, as requested:I have a number of sap databases that I want to import into a single database. If this is so simple as stated by some sapdb experts how on earth is it done? I know how to do backups and restores of whole databases but I can't find any good explanation of how to export/import users between sapdb's. step by step please!
1.
Create a text file that serves as the command file to
the RepMan command line interface (or shorter: repmcli).
This script should contain the commands to export and
import the catalogs as follows:
SET MAXERRORCOUNT <some number>
//
USE USER <src user name> <password> SERVERDB <src db name>
ON <src server name>
//
CATALOGEXTRACT USER OUTFILE '<ddl file name with full path>'
//
TABLEEXTRACT USER OUTFILE '<data file name with full path>'
//
USE USER <tgt user name> <password> SERVERDB <tgt db name>
ON <tgt server name>
//
TABLELOAD USER INFILE '<data file name with full path>'
OUTFILE <some restart file name>
//
CATALOGLOAD USER INFILE '<file name with full path>'
The command SET MAXERRORCOUNT forces the RepMan server to
allow this number of errors when processing a single command. In
case of processing data with DATALOAD or DATAEXTRACT
it means the number of rejected data rows,
in case of processing data with TABLEEXTRACT/TABLELOAD it means
the number of rejected tables
and in case of CATALOGLOAD/CATALOGEXTRACT it means the number of
failed ddl-statements.
The <src names> are the one on the database you want to
export the schema from (source). The <tgt names> are the one
on the database to import the exported schema (target).
The CATALOGEXTRACT/CATALOGLOAD USER command processes the
catalog of the currently logged on (through RepMan) user. Thus
with the USE USER command you should log on as the user whose catalog
to extract/load.
The commands TABLEEXTRACT/TABLELOAD export and import the data
of a table in SAP DB proprietary format. This allows a very fast
handling of the data. The data will be processed as DB pages (compare
ORACLE's direct path load). Additionally with the data TABLEEXTRACT
save the internal binary representation of the table processed.
The TABLEEXTRACT command creates 2 or more file off the name given -
one file named <data file name with full path>0000 which contains the
mapping of table names to data files and some
<data file name with full path>XXXX which are the data files itself.
Why must the TABLELOAD command be processed before the CATALOGLOAD
command?
Before loading the data the RepMan server compares the internal structure
of the target table (if existing) with that of the source table (saved
in data file). If they do not match the server rejects loading (remember
that the data is saved in db pages in the data file and thus must match
the table structure upon inserting).
But if there were made some modifications to the
source table (for instance some columns were removed) the kernel flags these
modifications in the table structure BUT does not adapt the data in the table
itself to these modifications. Ergo the internal structure contains these
flags and the data exported contains 'dead' data. These data will not fit
to a table freshly created with CREATE TABLE command created by CATALOGEXTRACT
command. The target table must undergo the same modifications as the
source table did or the RepMan server rejects loading the table.
To avoid this run TABLELOAD before CATALOGLOAD because:
he TABLELOAD command has a special feature - it creates the table
to load if it does not exist. To do this it uses the saved internal
binary structure of the table.
The CATALOGLOAD following the TABLELOAD will produces lots of errors
because it'll try to create objects that already exist (created by
TABLELOAD). These can be ignored.
Ok, I hope I don't have confused you too much.
This described behavior will be gone with version 7.4.4. because the kernel
changed processing data on TABLEEXTRACT - it adapts the data to the
catalog.
2.
Bring both database up if not already done.
3.
On the target database create the user whose catalog to import.
4.
Run the command file with the following command on the shell:
repmcli -u <src user name>,<password> -d <src db name>
-n <src server name> -E <number> -b <command file name>
This starts the RepMan server and logs on user <src user name> (it
is thus possible to omit the first USE USER command in the command file
because the options on the command line force RepMan to log this
user on; but I didn't want to make it too complicated).
The option -E forces the RepMan client repmcli to allow the specified
number of failed commands before stopping to process the command file.
5.
If the commands are done check the logfile repserver.log for errors.
Well, done. The users are duplicated. If something is missing or
incomprehensible let me know.
Hmm, looks like this is worth an entry in the HowTo wiki - it's on the
list.
Regards,
Steffen
--
Steffen Schildberg
SAP DB Team
SAP Labs Berlin
Eirikur Sveinn Hrafnsson [EMAIL PROTECTED] Chief Software Engineer idega Software, http://www.idega.com _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
