On the Source System:
1.
Take a full db2 offline
or online backup of the source system as explained above. You should include
the logs in the backup image, which is the default behavior as of DB2 Version
8.2 and 9.5. You need the logs because a rollforward is required following the
restore on the target system.
2.
Optionally, you can
create the export directory structure with labels, and you can archive SDM and
application specific file system content. You can use SAPinst to perform this
task. From the SAP Installation Master welcome screen, select:
<System Release> --> Software Life-Cycle Options --> System Copy --> IBM DB2 for Linux, Unix, and Windows -->Source System Export --> <System Variant> --> <Technical Stack> --> Export Preparation
By providing an export location, all the labels
and directory structures will be created in that location and these files can
be used in the target system.
3.
In a Java® or a double
stack system (ABAP+Java), you need to run a separate export for the Java engine
to archive SDM and application specific contents. For more information about
this step and the previous step, please review the SAP system copy guide for
your release.
On the Target System:
1.
Run SAPinst and from the
SAP Installation Master welcome screen, select:
<System Release> --> Software Life-Cycle Options --> System Copy --> IBM DB2 for Linux, Unix, and Windows -->Target System Installation --> <System Variant> --> <Technical Stack>
2.
Follow the normal
installation procedure. When asked for a SID, either select the same SID as the
source system, or a new SID.
3.
On the database specific
screen, select Homogeneous System Copy
(Database copy method)
4.
Continue with the
installation procedure. Enter the database ID, the database ports, and the
connect user. Remember that the connect user must be identical to the source
system, even if the SID is different.
5.
If you are installing a
double stack system, you will be asked to enter the location of the Java
export, as well as the username and password of the Java administrator. The
information you enter must match the source system, but you can change it after
the system copy.
6.
After you enter all the
required parameters, the install continues up to the step where the restore is required. 
7.
When the restore is
required, you will see a Message Box pop-up as shown in the figure below.
Select Cancel to abort the installation and run the database restore.
Alternatively, you can leave the Message Box pop-up open, complete the restore from
a separate window, and select OK when the restore is complete. 
8.
If you made the
selection in the previous step to abort the installation, you see another
Message Box. Select Stop to confirm that you want to stop the
installation and exit SAPinst.
9.
Run the redirected
restore using one of the methods specified in the following section.
10.
Restart SAPinst and
continue the installation as described in the SAP installation guide for your
release.
11.
if you changed the SID,
you need to enter the following command to update the LOGARCHMETH1 database
configuration parameter to point to the new SID:
db2 update
database configuration for <NEW_SID> using LOGARCHMETH1
/db2/<NEW_SID>/log_archive
|
There are three
different methods you can use to restore the database:
- Generate a script using the SAP brdb6brt tool.
From the source system, invoke the tool by
issuing the following command:
brdb6brt -s
<SID> -bm RETRIEVE -user <instance_owner> -using
<password>
|
For example:
brdb6brt -s
LR1 -bm RETRIEVE -user db2lr1 -using PASS123
|
The tool generates a script in the form
SID_NODE000X.src. The tool also creates a file named SID_NODE000X.brp that
includes a log of the steps performed. You can use this file to trace errors if
they occur.
Modify the generated script to fit the
specifications of the target system. You can change the SID, storage paths,
location of the log directory, etc. (note that if you are using automatic
storage, there is no need to set container paths). After making your
modifications, run the script from the CLP using the command:
db2 -tvf
<SID>_NODE0000.scr
|
The Download section at the end of this article contains a
link to a sample redirected restore script.
You can also use the brdb6brt tool to create a backup and generate the restore
script in one step. For more information on the script or on the brdb6brt tool, refer to the SAP DB6 Database Administration Guide.
- Generate a script using DB2's
redirected restore.
You can invoke the restore utility through the
DB2 command line processor (CLP) or the db2Restore application programming
interface (API). To run it from the CLP, issue the following command on the
target system:
db2 restore db <SID> from <location>
taken at
<timestamp>
redirect generate script <script>.clp
|
For example:
db2 restore db LR1 from /backup/LR1 taken
at 20090804090733 redirect generate
script LR1restore.clp
|
Modify the generated script to fit the specifications
of the target system. You can change the SID, storage paths, location of the
log directory, etc. (note that if you are using automatic storage, there is no
need to set container paths). After making your modifications, run the script
from the CLP using the command:
db2 -tvf LR1restore.clp
|
- Alternatively, you can use the
CLP to manually issue the redirected restore command and set the container
paths (note that if you are using automatic storage, there is no need to
set the container paths).
For example:
db2 restore
database LR1 from /mnt/LR1backup taken at 20090914135805 redirect
db2 restore
database LR1 continue
|
Upon completion of the
restore, you must perform a rollforward on the database.
For example:
db2
rollforward db LR1 to end of logs
|
If there are no logs
available or if there is no need to rollforward, you can issue the command with
the stop option.
For example:
db2
rollforward db LR1 stop
|
Alternatively, you can
add the rollforward command to the generated redirected restore script
described previously.
Automatic storage is a
feature that allows DB2 to control database growth without having to preset any
specific sizes for the database or the tablespace containers. This results in
less user interference and fewer interruptions due to space constraints during
normal workload.
With releases of DB2
prior to 9.7 you could only enable automatic storage during database creation
(this is the default behavior starting with DB2 Version 9.1). With DB2 9.7 you
can also convert your database and tablespaces to use automatic storage after
database creation.
You can use the system
copy method to convert your database to automatic storage on the same system,
or you can combine a system copy with a conversion to auto storage in one step
by doing the following:
On the Source System:
1.
Issue the following
command to enable automatic storage at the database level:
db2 ALTER
DATABASE <dbname> ADD STORAGE ON <path1> [<path2>,...,<pathn>]
|
For example:
db2 ALTER
DATABASE LR1 ADD STORAGE ON ’/db2/LR1/sapdata1’,’/db2/LR1/sapdata2’,
’/db2/LR1/sapdata3’,
’/db2/LR1/sapdata4’
|
2.
Backup the database
using the backup command as explained previously.
On the Target System:
1.
Enable automatic storage
at the tablespace level during the restore by updating the redirected restore
script or by running the restore at the command line as explained previously.
Set the containers to use auto storage as follows:
db2 set
tablespace containers for <tablespace_id1> using automatic
storage;
db2 set
tablespace containers for <tablespace_id2> using automatic
storage;
...
|
Note that the tablespace ID can be retrieved
from the tablespace snapshot. It is also included in the generated redirected
restore script.
For example:
db2 get
snapshot for tablespaces on <db_name> |grep ”Tablespace ID”
|
2.
After the database has
been fully converted to automatic storage, you should make a backup of it.
No comments:
Post a Comment