Tivoli Storage Manager
Upgrade from Version 5.5 to 6.2
Pre Requests
=============
# Ensure that the server that you plan to
upgrade is at version 5.3.6 or later.
è lslpp –l | grep –I tivoli
# Ensure that the system where the V5
server is located meets the minimum requirements.
Use
the information in Hardware and software requirements for the V5 server system
that is
being upgraded to determine whether you need to update your system
before you continue.
Hardware
Requirements
POWER4™, POWER5™, POWER6™, POWER7™systems computer (64-bit)
AIX V5.3 (64 bit only)
Memory:
20 GB of memory or more is optimal and more
efficient for the new Tivoli Storage Manager with integrated DB2. For this upgrade, there
was 20 GB of memory for each Tivoli Storage Manager instance.
è prtconf
Disk Space :
*
5 MB for the /var directory
*
30 MB for /opt directory
*
2 GB for the /opt/tivoli /tsm
directory----Need to check
*
360 MB for the /tmp directory
*
300 MB for the /usr directory
*
2 GB in the home directory----------Need to check
è df –m
Software Requirements:
*
AIX 5.3 Technology Level (TL) 11 and Service Pack (SP) 1
è oslevel -r
*
Minimum C++ runtime level with the xlC.rte 9.0.0.8 and xlC.aix50.rte 9.0.0.8
filesets. These filesets are included in the June 2008 cumulative fix package
for IBM® C++ Runtime Environment Components for AIX.
è
lslpp –L x1C.rte
è lslpp –L qsksa.rte----Check
*
For upgrades to Tivoli Storage Manager Version 6.2, the bos.iocp.rte fileset is
required.
# Ensure that the system where you plan to
install the V6.2 server meets requirements.
Check the operating system level and the
platform against the list of supported operating
systems and platforms.
General Checks :
* Make sure that the Asynchronous I/O is enabled
You can enable this using Enable this manually using "smit aio"
General Checks :
* Make sure that the Asynchronous I/O is enabled
You can enable this using Enable this manually using "smit aio"
lsattr -El aio0 => to chk whether AIO enabled
* Make sure IOCP is enabled on AIX platforms
* Make sure IOCP is enabled on AIX platforms
lsdev –Cc iocp è to chk whether IOCP enabled
If not enabled then you can enable using "smitty iocp"
* Make sure all the installation mount points are created as rw file systems ..
Modifying
the server before the upgrade
=============================================
# From a Tivoli® Storage Manager
administrative command line, issue the command:
convert ussfilespace
This command fixes a problem that might
exist in older Tivoli Storage Manager databases. If the problem does not exist
in your database, the command completes quickly. If the problem exists in your
database, the command might take some time to run.
Important: Do not skip this step. If your
database has the problem and you do not run this command now, the DSMUPGRD
PREPAREDB utility fails when you run it. You must then restart the V5 server
and run the CONVERT USSFILESPACE command before continuing with the upgrade
process.
Disabling
the sessions
===========================
1.
Prevent all clients, storage agents, and other servers from starting new
sessions with the server. Use the
commands:
disable sessions client
disable sessions server
2.
Prevent administrative activity from any user ID other than the administrator
ID that is being used to perform the upgrade preparation. Lock out other
administrator IDs if necessary:
lock admin administrator_name
3.
Check whether any sessions exist, and notify the users that the server is going
to be stopped. To check for existing sessions, use the command:
query session
4.
Cancel sessions that are still running. Use the command:
cancel session
Backing
up storage pools and the server database
======================================================
Immediately before upgrading the server,
back up primary storage pools to copy storage pools, and perform a full
database backup.
1.
Back up primary storage pools to copy storage pools using the BACKUP STGPOOL
command. If you have been performing regular backups of
the storage pools, this step backs up only the data that was added to
the primary storage pools since they were last backed up.(Not Applicable for
the current upgrade)
2.
Back up the database using the following command. Use either a full or snapshot
backup type.
backup db type=type devclass=device_class_name
The device class that you specify must exist and have volumes that are
available to it. For example, to perform a snapshot backup of your database to
the TAPECLASS device class using scratch volumes, enter:
backup db type=dbsnapshot devclass=tapeclass
To use specific volumes instead of scratch volumes, specify the volume
names in the command.
Consider making two copies of the backup to protect the backup from
media failures.
Backing
up configuration information
=======================================
Before installing the new version, back up
critical files and information for the server. Store the files in a safe place,
because they are needed after the installation of the new software version is
completed. You also need these files if you must revert to the previous version
after the upgrade.
1.
Back up device configuration information:
backup devconfig filenames=file_name
2.
Back up volume history information:
backup volhistory filenames=file_name
Ensure that the volume history includes information about the database
backup that you completed in the preceding steps. For example, issue the
command:
query volhistory type=dbbackup
3.
Make copies of these files, which are located in the default directory for the
server:
* server options file, typically named dsmserv.opt
* dsmserv.dsk
4.
Optional: Make a copy of the accounting log file, dsmaccnt.log.
5.
Back up any scripts that have been used to perform daily housekeeping for the
server. Examine the scripts for changes that are needed after the
upgrade.
6.
Store the device configuration file, the volume history file, the server
options file, and the other files in a safe place.
Select a location that is not on the system that is being upgraded.
Creating
a summary of database contents
===========================================
Create a summary of the contents of the
original database. After the upgrade, you can use the same commands to compare
the results and to confirm that the database contents are intact.
Macro will be used for this..
Macro
File
===========
select node_name, count(*) as "Number
of Filespaces" from filespaces group by node_name order by 2
select platform_name, count(*) as
"Number of Nodes" from nodes group by platform_name
select count(*) as "Number of
Administrators" from admins
select node_name,sum(num_files) as
"Number of Backup Files" from occupancy where type='Bkup' group by
node_name
select node_name,sum(num_files) as
"Number of Archive Files" from occupancy where type='Arch' group by
node_name
select count(*) as "Number of Schedule
Associations" from associations
select count(*) as "Number of
Backupsets" from backupsets
select count(*) as "Number of Client
Option Sets" from cloptsets
select count(*) as "Number of
Collocation Groups" from collocgroup
select count(*) as "Number of Archive
CopyGroups" from ar_copygroups
select count(*) as "Number of Backup
CopyGroups" from bu_copygroups
select count(*) as "Number of Data
Movers" from datamovers
select count(*) as "Number of Device
Classes" from devclasses
select count(*) as "Number of Domains"
from domains
select count(*) as "Number of
Drives" from drives
select count(*) as "Number of
Libraries" from libraries
select count(*) as "Number of Library
Volumes" from libvolumes
select count(*) as "Number of
Volumes" from volumes
select count(*) as "Number of
Management Classes" from mgmtclasses
select count(*) as "Number of Node
Groups" from nodegroup
select count(*) as "Number of Device
Paths" from paths
select count(*) as "Number of Policy
Sets" from policysets
select count(*) as "Number of Client
Schedules" from client_schedules
select count(*) as "Number of Admin
Schedules" from admin_schedules
select count(*) as "Number of Server
Scripts" from scripts
select count(*) as "Number of Servers
Defined" from servers
select count(*) as "Number of Servers
Groups Defined" from server_group
select count(*) as "Number of Storage
Pools Defined" from stgpools
select node_name, count(*) as "Number
of Filespaces" from filespaces group by node_name order by 2
select platform_name, count(*) as
"Number of Nodes" from nodes group by platform_name
select count(*) as "Number of
Administrators" from admins
select node_name,sum(num_files) as
"Number of Backup Files" from occupancy where type='Bkup' group by
node_name
select node_name,sum(num_files) as
"Number of Archive Files" from occupancy where type='Arch' group by
node_name
select count(*) as "Number of Schedule
Associations" from associations
select count(*) as "Number of
Backupsets" from backupsets
select count(*) as "Number of Client
Option Sets" from cloptsets
select count(*) as "Number of
Collocation Groups" from collocgroup
select count(*) as "Number of Archive
CopyGroups" from ar_copygroups
select count(*) as "Number of Backup
CopyGroups" from bu_copygroups
select count(*) as "Number of Data
Movers" from datamovers
select count(*) as "Number of Device
Classes" from devclasses
select count(*) as "Number of
Domains" from domains
select count(*) as "Number of
Drives" from drives
select count(*) as "Number of
Libraries" from libraries
select count(*) as "Number of Library
Volumes" from libvolumes
select count(*) as "Number of
Volumes" from volumes
select count(*) as "Number of
Management Classes" from mgmtclasses
select count(*) as "Number of Node
Groups" from nodegroup
select count(*) as "Number of Device
Paths" from paths
select count(*) as "Number of Policy
Sets" from policysets
select count(*) as "Number of Client
Schedules" from client_schedules
select count(*) as "Number of Admin
Schedules" from admin_schedules
select count(*) as "Number of Server
Scripts" from scripts
select count(*) as "Number of Servers
Defined" from servers
select count(*) as "Number of Servers
Groups Defined" from server_group
select count(*) as "Number of Storage
Pools Defined" from stgpools
Stopping
the server before installing the upgrade
=======================================================
Stop all server processes and dismount any
tapes that are mounted. Then stop the server.
The commands in the following procedure are
Tivoli® Storage Manager administrative commands.
1.
Cancel sessions if any are still running. Use the command:
cancel session
Allow time for the sessions to be stopped. Some sessions, such as backup
by a backup-archive client, might take some time to stop.
2.
Determine whether server processes are running. Either cancel processes, or
allow them to complete. Use the commands:
query process
cancel process process_number
Allow time for the processes to be stopped. Some processes, such as
storage pool migration, might take some time to stop.
3.
After all sessions and processes are stopped, determine whether any tapes are
mounted. Dismount any tapes that are mounted. Use the commands:
query mount
dismount volume volume_name
4.
Stop the server. Use the command:
halt
Installing
the upgrade utilities on AIX systems ====================================================
Install the upgrade utilities on the
system. The package to install is available for download from the FTP downloads
site. The upgrade utilities are used to prepare and extract the database from
the original server.
1.
Obtain the upgrade utilities package from the FTP downloads site.
1. Go to
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server-upgrade/v5r5/
2. Navigate to the directory that names the operating system that your
V5 server runs on. From that directory, open the 5.5.x.x directory. The 5.5.x.x
number must be the same as or later than the level of the V5 server that you
are upgrading.
3. Select the package that matches your platform, and download it to a
convenient location on the server system. The name of the package has the
following form:
5.5.x.x-TIV-TSMUPG-AIX.tar.gz
The numbers at the beginning of the package name identify the release
level of the upgrade utilities package. The level of the upgrade utilities
package must be the same as or later than the level of the V5 server that you
are upgrading.
4. Optional: To install messages in a language other than English, open
the LANG directory, and download a language package. Translated messages are
available in the usual set of languages for a V5 server.
2.
Log in with the root user ID.
3.
Ensure that the system has the following file sets installed:
* xlC.rte 8.0.0.5, or later
* gsksa.rte 7.0.4.11
You can use the following commands to check for these file sets:
lslpp -L xlC.rte
lslpp -L gsksa.rte
If needed, you can obtain the gsksa.rte file set from any of the regular
V5.5 maintenance packages for the AIX® server. The maintenance packages are
available on the FTP downloads site:
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server/v5r5/AIX/
4.
Extract the contents of the upgrade utilities package. If you downloaded a
language package, also extract the contents of that package.
5.
Access the System Management Interface Tool (SMIT).
1. Enter smitty install_update
2. Select Install and Update Software > Install and Update from ALL
Available Software.
6.
Select the INPUT device. Specify the directory location of the upgrade
utilities package on the system.
7.
Select Software to Install. Press F4 or Esc+4 for the list of available file
sets in the directory.
8.
Select the file sets for the upgrade utilities, the device driver, and
optionally the language pack. The file set for the upgrade utilities is
tivoli.tsmupg.server. Optional language packs include messages for languages
other than U.S. English.
9.
Set COMMIT software updates to Yes. Press F4 or Esc+4.
10.
Set SAVE replaced files to No.
11.
Ensure that the default settings for the options in the window for all the
selected file sets show success.
12.
Press Enter, and respond to the ARE YOU SURE? question by pressing Enter again.
The installation begins.
13.
When the installation is complete, exit the SMIT program.
14.
Optional: If you installed a language package, ensure that the locale
environment variable is set to use it. Enter the following command to set the
locale environment variable for messages:
export LC_MESSAGES=xxxx
where xxxx is the locale that you want to use. For example, use it_IT
for Italian. The upgrade utilities run with the locale that you specify if the
following statements are true:
* The locale is installed on the system.
* The upgrade utilities support the locale.
* The language package that you installed for the upgrade utilities
matches the local
Setting
Environment values
============================
After installing the upgrade utility
package, you must set environment variables in the shell from which you will
run the utilities. An environment variable describes the operating environment
of a process, such as the home directory or terminal in use.
DSMSERV_DIR
Specifies the installed location of the upgrade utilities.
By default the location is:
* AIX operating systems /usr/tivoli/tsm/upgrade/bin
export DSMSERV_DIR=/usr/tivoli/tsm/upgrade/bin
Preparing
the database of a V5 server for upgrade
==================================================
Before extracting the data from the
database, you must prepare the server database by using the DSMUPGRD PREPAREDB
utility.
If you have multiple servers on a single
system, you must repeat this task for each server.
1.
Ensure that you have completed all preparation steps.
2.
Log in using the root user ID on the system that has the original server.
3.
Change to the instance directory for the server that you are upgrading. The
instance directory is the directory that contains the files such as dsmserv.dsk
for the server.
4.
Prepare the database. Direct the output of the process to a file for
monitoring.
AIX operating systems
From the instance directory for the server that you are upgrading, issue
the following command to run the process in the background and direct the
output to the file called prepare.out:
nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd preparedb >prepare.out
2>&1 &
5.
Monitor the process for errors and warning messages. The final message
indicates success or failure of the operation. From the instance directory
for
the server that you are upgrading, issue the following command to monitor the process:
tail -f prepare.out
6.
Ensure that the prepare operation is completed successfully before continuing
to the next step. If the prepare operation fails,
you might need to restart the V5 server to
fix the problem and run the prepare operation again. If the server being
upgraded is a V5.3 or V5.4 server,
you
might need to restore the database using a backup before you can restart the
server to correct the problem.
Uninstalling
the V5 program before installing V6.2
===================================================
For best results when you are upgrading the
server to V6.2 on the same system where the V5 server is located, uninstall the
V5 server program before installing the V6.2 server program.
Uninstalling the V5 program on AIX® systems
Uninstall the V5 server, server license,
and device driver. Do not remove the database, recovery log, or any other
related files or directories, such as the server options file.
*
For a V5.4 or V5.5 server, issue the following commands:
/usr/sbin/installp -ug tivoli.tsm.license.aix5.rte64
/usr/sbin/installp -ug tivoli.tsm.devices.aix5.rte
/usr/sbin/installp -ug tivoli.tsm.server.aix5.rte64
Installing
the V6.2 server
===========================
Ensure that you have completed all upgrade
preparation steps, including backup of the server database, before beginning
the installation procedure. The server will not be available until after
installation and upgrade steps are completed.
# Log on to the system.
AIX operating systems
Log in using the root user ID.
#If you downloaded the program from
Passport Advantage® as an executable file, complete the following steps.
AIX operating systems
1. Verify that you have enough space to store the installation files
when they are extracted from the product package.
Space requirements for AIX
* 1700 MB of disk space to
store the downloadable part.
* 2365 MB of disk space to
unpack the part.
NOTE: The AIX Version
9.0.0.8 C Runtime Library consumes approximately 78 MB when the part is
unpacked. Installation of the Version 9.0.0.8 Runtime Library is optional
depending on whether the minimum required library level is already installed.
* 1770 MB in /opt and 336 MB in
/usr --- disk space for the installed product.
* 26 MB of space in /tmp to run
the installation program.
2. Change to the directory where you placed the executable file.
Tip: Ensure that the file is in the directory where you want the
extracted files to be located. In a later step, the files are extracted to that
directory.
3. Change the file permissions by entering the following command:
chmod a+x package_name.bin
The package_name is CZG6sML.bin
4. Extract the installation files:
./CZG6sML.bin
The package is large, so the extraction takes some time
#You can use either the graphical wizard or
the console wizard.
AIX operating systems
* Start the graphical wizard:
./install.bin
* Start the console wizard:
./install.bin -i console
Select the language for the installation
and follow the instructions.
AIX operating systems
1. You must accept the license agreement to complete the installation.
2. Select the components to install. You must select at least the
server, license, and Tivoli
Storage Manager Server Languages in the component
list. Typical installations also include the
device driver. For information about other components that you can choose to
install, see the information
about installing a new server.
3. On the Server Language Selection page, select English (not UTF8) and
any other language packs that you need.
You
must select English because it installs the tivoli.tsm.server.msg.en_US
package, which includes the help messages.
When the installation is complete, verify
that you see a message that the installation is successful.
Important: If there are any errors during
the installation, a summary panel lists the errors and directs you to an error
log file. Fix the errors before continuing with the upgrade.
The installation log is stored in the
following location:
/var/tivoli /tsm
# Download and apply any applicable fixes
that have been released for the server. Go to the product support site,
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager,
and click Download. Search for server updates.
You can also check the FTP downloads site: ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server/
#Creating
the directories and the user ID for the upgraded server instance
===========================================================================
Create the directories that the server
instance needs for database and recovery logs, and create the user ID that will
own the server instance.
1.
Create the user ID that will own the server instance. You use this user ID when
you create the server instance in a later step.
AIX operating systems
Create a user ID and group that will be the owner of the Tivoli® Storage
Manager server instance.
1. Create the user ID and group.
Restriction: The user ID and
group name must comply with the following rules:
* In the user ID, only
lowercase letters (a-z), numerals (0-9), and the underscore character ( _ ) can
be used. The user ID must be 8 characters or less, and cannot start with ibm,
sql, sys, or a numeral.
* In the group name, only
lowercase letters (a-z), numerals (0-9), and the underscore character ( _ ) can
be used. The group name must be 8 characters or less, and cannot start with
ibm, sql, or a numeral.
For example, create user ID
tsminst1 in group tsmsrvrs. The following examples show how to create this user
ID and group using operating system commands.
AIX operating systems
# mkgroup id=1001 tsmsrvrs
# mkuser id=1002 pgrp=tsmsrvrs
home=/home/tsminst1 tsminst1
# passwd tsminst1
2 .
Create directories that the server requires. You need unique, empty directories
for each of the items shown in the following table.
Create the database directories, the active
log directory, and the archive log directory on different physical volumes.
See
the planning information for details.
AIX operating systems
The instance directory for the server,
which is a directory that will contain files specifically for this server
instance (the server options file and other server-specific files)
eg : mkdir /home/tsminst1/tsminst1
Tip: For this example, the instance
directory is created in the home directory for the instance owner ID, tsminst1.
You can place it in other locations.
The database directories
eg:
mkdir /tsmdb001
mkdir /tsmdb002
mkdir /tsmdb003
mkdir /tsmdb004
Active log directory
eg: mkdir
/tsmlog
Archive log directory
eg: mkdir
/tsmarchlog
Optional: Directory for the log mirror for
the active log
eg: mkdir /tsmlogmirror
Optional: Secondary archive log directory
(failover location for archive log)
eg:
mkdir /tsmarchlogfailover
3 . For all directories that were created
for the server instance, ensure that the user ID that owns the server instance
has access.
The directories to check include the
instance directory and all database and log directories.
AIX operating systems
Change the owner of the directories that were created to the user ID for
the server instance.
Below Commands can be used in AIX to change
the ownership
chown <userid>:<goupid> <filename>
Eg:
chown tsminst1:tsmsrvrs /home/tsminst1
4 .For all disk space that is used by the
V5 server for storage pools (device types of FILE and DISK), change ownership
or access control so that the user ID
that will own the upgraded Tivoli Storage
Manager server instance has ownership or read/write permission.
Use
the appropriate method for your operating system.
We can Use below Commands to Do the above steps
mkvg -y tsminstvg -s'256' hdisk19
We can Use below Commands to Do the above steps
mkvg -y tsminstvg -s'256' hdisk19
mkvg -y tsminstdbvg -s'256' hdisk2 hdisk3
hdisk12 hdisk13 hdisk14 hdisk20
mkvg -y tsminstlogvg -s'256' hdisk16
hdisk17 hdisk18 hdisk15
mklv -y tsminst -t jfs2 tsminstvg 7
mklv -y tsminst -t jfs2 tsminstvg 7
mklv -y db_dir_001lv -t jfs2 tsminstdbvg
250
mklv -y db_dir_002lv -t jfs2 tsminstdbvg
250
mklv -y db_dir_003lv -t jfs2 tsminstdbvg
250
mklv -y db_dir_004lv -t jfs2 tsminstdbvg
250
mklv -y db_dir_005lv -t jfs2 tsminstdbvg
250
mklv -y db_dir_006lv -t jfs2 tsminstdbvg
250
mklv -y tsminstlv -t jfs2 tsminstvg 1
crfs -v jfs2 -d tsminst -m /home/tsminst1
-p'rw' -a agblksize='4096' -a logname='INLINE'
crfs -v jfs2 -d db_dir_001lv -m
/tsminst1/db_dir_001 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d db_dir_002lv -m
/tsminst1/db_dir_002 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d db_dir_003lv -m
/tsminst1/db_dir_003 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d db_dir_004lv -m
/tsminst1/db_dir_004 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d db_dir_005lv -m
/tsminst1/db_dir_005 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d db_dir_006lv -m
/tsminst1/db_dir_006 -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d log_actlv -m
/tsminst1/log_act -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d log_actmlv -m /tsminst1/log_actm
-p'rw' -a options='cio' -a agblksize='4096' -a logname='INLINE'
crfs -v jfs2 -d log_arclv -m
/tsminst1/log_arc -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d log_arcflv -m
/tsminst1/log_arcf -p'rw' -a options='cio' -a agblksize='4096' -a
logname='INLINE'
crfs -v jfs2 -d opt_tsm -m /opt/tivoli /tsm -p'rw' -a
agblksize='4096' -a logname='INLINE'
Upgrading the server manually using
utilities
==============================================
Use the utilities to upgrade the server
using a command interface.
Before beginning the upgrade procedure, you
must complete all preceding steps to prepare for the upgrade, to install the
upgrade utilities, to install the V6.2 server program, and to create the
directories and user ID for the server instance.
Complete the following steps:
Extracting the data to media
==================================
You can extract the data from the original server database to sequential
media. The sequential media can be tape, or disk space that is defined with the
FILE device class.
1.
Log in using the root user ID on the system that has the original server. Log
on with the administrator ID on a Windows® system.
2.
Ensure that the device that you want to use to store the extracted data is
available. The server database and the device configuration file must contain a
valid device class definition for the device.
3.
From the instance directory for the server that you are upgrading, issue the
command to start the extraction. Direct the output of the process to a file for
monitoring. For example, issue the following command, on one line:
AIX operating systems
nohup /usr/tivoli/tsm/upgrade/bin/dsmupgrd extractdb devclass=lto4
manifest=./manifest.txt >extract.out 2>&1 &
/usr/tivoli/tsm/upgrade/bin/dsmupgrd
extractdb devclass=lto manifest=./manifest.txt >extract.out 2>&1
&
ip: Messages that are issued during the
extract operation are not saved in the server activity log. Direct the output
of the utility to a file, as shown in the examples, to record the messages.
4.Monitor the process for errors and warning messages, and for items
that you might need to take action on.
A message near the end of the process
output indicates success or failure of the operation:
*
Success message: ANR1382I EXTRACTDB: Process 1, database extract, has
completed.
*
Failure message: ANR1396E EXTRACTDB: Process 1, database extract, has completed
with errors.
For example, from the instance directory
for the server that you are upgrading, issue the following command to monitor
the process:
tail -f extract.out
The length of time that the process runs
depends on the size of the database. The time will be approximately as much as
the time required for a full backup of the database.
Creating and formatting the new database
==============================================
Create the server instance and format files
for an empty V6.2 database.
1.
Log on to the system where you installed the V6.2 program.
AIX operating systems
Log in using the root user ID. Complete the following checks:
1. Verify that the home directory exists for the user ID that owns the
server instance. For example,
if
the user ID is tsminst1, the home directory is /home/tsminst1.
2. Verify that a configuration profile exists for the user ID in its
home directory.
If
necessary, create the configuration profile. For example, create a .profile
file if you are using the Korn shell (ksh).
The .profile file can be empty.
2.
Create a Tivoli® Storage Manager instance using the db2icrt command.
AIX operating systems HP-UX operating
systems Linux operating systems Sun Solaris operating systems
Enter the following command on one line. For the instance name, specify the
user ID that you created to own the instance.
/opt/tivoli /tsm/db2/instance/db2icrt
-a SERVER \
-u instance_name instance_name
For example, if the user ID for this instance is tsminst1, use the
following command to create the instance.
Remember: From this point on, use this new user ID when configuring your
Tivoli Storage Manager server. Log out of the root user ID,
and
log in using the user ID that is the instance owner.
3. Log on to the system using the user ID
that owns the V6.2 server instance (the instance user ID).
4. Copy the configuration files to the
instance directory that you created for the new server. The files are the
configuration files that you saved from the original V5 server:
*
Device configuration
*
Server options file (typically named dsmserv.opt)
For example, if you created the instance
directory that is shown in the example in the step to create directories for
the V6.2 server,
copy the files into the following
directory:
*
AIX operating systems
/home/tsminst1/tsminst1
#
Ensure that the user ID that owns the V6.2
server (the instance user ID) has ownership or read/write permission to the
files that you copied.
5. Edit the server options file.
1.
Remove any options that are not supported for V6.2. For the list of deleted
options, see Table 3 .
2.
Ensure that the server options file contains at least one VOLUMEHISTORY option
and at least one DEVCONFIG option. Because a volume history file and a device
configuration file are required when you must restore the database, generate
copies of these files automatically to help ensure that the files are available
when needed.
3.
Check whether the server options file includes the TXNGROUPMAX option with a
value, and if it does, what the value is. You might want to change the current
value because the default value for this option changes from 256 to 4096 with
V6.2. The increased value can improve the performance for data movement
operations such as storage pool migration and storage pool backup.
* If the server options file does not include this option, the server
automatically uses the new default value of 4096.
* If the server options file includes a value for this option, the
server uses that specified value. If the specified value is less than 4096,
consider increasing the value, or removing the option so that the server uses
the new default value.
6. Change the default path for the
database.
AIX operating systems
Change the default path for the database to be the same as the instance
directory for the server. Issue the command:
db2 update dbm cfg using dftdbpath instance_directory
For example:
db2 update dbm cfg using dftdbpath /home/tsminst1/tsminst1
7 Change to the instance directory that you
created for the server.
8 Create and format the database and
recovery logs. In the command, specify the directories that you created for the
database and logs.
The directories must be empty.
AIX operating systems
For example, to get an active log size of 16 GB (16384 MB, the default
size), issue the following command, on one line:
/opt/tivoli /tsm/server/bin/dsmserv
loadformat \
dbdir=/tsmdb001,/tsmdb002,/tsmdb003,/tsmdb004 \
activelogsize=16384 activelogdir=/tsmlog \
mirrorlogdir=/tsmlogmirror archlogdir=/tsmarchlog
9. Monitor the process for errors and
warning messages. The final message indicates success or failure of the
operation.
Loading the extracted data into the new
database
====================================================
After you have formatted an empty database
using the DSMSERV LOADFORMAT utility, load the data that you extracted from the
original server database.
The following requirements must be met:
*
The manifest file from the DSMUPGRD EXTRACTDB operation must be available.
*
The server options file must contain an entry for the device configuration
file.
*
The device configuration file must have information about the device class that
is specified in the manifest file.
*
The media that contains the extracted database must be available to the V6.2
server. The device must be physically attached to the system, and the
permissions must be set to grant access to the media for the user ID that owns
the V6.2 server instance.
Perform the following steps:
1.
Verify that the V6.2 server can access the extracted data.
* If the extracted data is on tape, the tape drive must be physically
attached to the system.
* If the extracted data was stored using a FILE device class:
1. Log on to the system using
the root user ID.
2. Change the ownership of the
files to the user ID that owns the V6.2 server (the instance user ID).
2.
For the manifest file that was created by the extraction process, ensure that
the user ID that owns the V6.2 server (the instance user ID) has
ownership or read/write permission.
3.
Log on with the server instance user ID.
4.
Ensure that the device configuration file from the original server is
available.
1. Verify that the server option file includes the DEVCONFIG option, and
that the option specifies the full path of the device configuration file.
2. Verify that the device configuration file is available in the
location specified by the DEVCONFIG option.
3. Verify that the permissions on the device configuration file allow
read access for the user ID that owns the V6.2 server instance.
5.
Verify that the contents of the device configuration file are correct. The
device class that was used for the extraction step is recorded in the manifest
file, and that device class must exist and be valid on the V6.2 system.
1. Verify entries for FILE device classes. For example, paths might be
different on the system.
2. Verify entries for tape and other devices. For example, the device
names might have changed.
6.
Verify that the contents of the manifest file are correct. The manifest file
contains a list of volumes to be used when loading the extracted data into the
new database. For example, if the manifest file contains a list of volumes
belonging to a FILE device class, ensure that the fully qualified path to the
volumes is correct for the system.
7.
Issue the DSMSERV INSERTDB command to load an extracted server database into the
prepared, empty V6.2 database. Direct the output of the process to a file for
monitoring. For example, enter the following command on one line:
1.1 Abstract
Version 5 to Version 6.x, performance can be adversely affected.
1.2 Content
The problem will be fixed with APAR IC79161.
To prevent performance impacts until the APAR fix is available, add the following options to the server options file, dsmserv.opt, before starting DSMSERV INSERTDB:
ALLOWREORGTABLE NO
ALLOWREORGINDEX NO
AIX operating systems
nohup /opt/tivoli/tsm/server/bin/dsmserv insertdb \
manifest=./manifest.txt >insert.out 2>&1 &
8.
Monitor the process for errors and warning messages, and for items that you
might need to take action on. The system displays interim statistics about the
operation. A message near the end of the process output indicates success or
failure of the operation:
* Success message: ANR1395I INSERTDB: Process 1, database insert, has
completed.
* Failure message: ANR1396E INSERTDB: Process 1, database insert, has
completed with errors.
For example, issue the following command to monitor the process:
tail -f insert.out
The length of time that the process runs depends on the size of the
database.
9.
If you used a tape device, after the insertion operation is complete remove or
check out from the library the tape that holds the extracted data. Prevent the
tape from being reused until you are sure that you do not need to run the
insertion operation again
Configuring the system for database backup
=============================================
The database manager and the Tivoli®
Storage Manager API must be configured so that the database manager can back up
the server database. The configuration is completed for you automatically if
you use the upgrade wizard (dsmupgdx). If you do not use the wizard, you must
complete the configuration manually.
Configuring the system for database backup
on AIX
If you did not use the upgrade wizard, you
must complete the configuration for the database backup manually.
In the following steps, the examples use
tsminst1 for the server instance user ID and /home/tsminst1/tsminst1 for the
Tivoli® Storage Manager server instance directory.
1.
Set the DSMI_ api environment-variable configuration for the database instance:
1. Log in using the tsminst1 user ID.
2. When user tsminst1 is logged in, ensure that the DB2 environment is
properly initialized. The DB2 environment is initialized by running the
/home/tsminst1/sqllib/db2profile script, which normally runs automatically from
the user ID's profile. If /home/tsminst1/.profile does not run the db2profile
script, add the following lines to /home/tsminst1/.profile:
if [ -f /home/tsminst1/sqllib/db2profile ]; then
. /home/tsminst1/sqllib/db2profile
fi
3. Add or update the following lines to the userprofile file in the
/home/tsminst1/sqllib directory:
AIX operating systems
export DSMI_CONFIG=/home/tsminst1/tsminst1/tsmdbmgr.opt
export DSMI_DIR=/usr/tivoli/tsm/client/api/bin64
export DSMI_LOG=/home/tsminst1/tsminst1
2.
Log out and log in again as tsminst1, or issue this command:
. ~/.profile
3.
Create a file called tsmdbmgr.opt in the /home/tsminst1/tsminst1 directory and
add the following line:
SERVERNAME TSMDBMGR_TSMINST1
4.
Add the following lines to the Tivoli Storage Manager API dsm.sys configuration
file. The dsm.sys configuration file is in the following default location:
* AIX operating systems /usr/tivoli/tsm/client/api/bin64
Avoid placing the server name, TSMDBMGR_TSMINST1, first in dsm.sys
because it should not be the system-wide default. In this example, the added
lines are after the stanza for server_a.
Servername server_a
COMMMethod TCPip
TCPPort 1500
TCPServeraddress node.domain.company.COM
servername TSMDBMGR_TSMINST1
commmethod tcpip
tcpserveraddr localhost
tcpport 1500
passwordaccess generate
passworddir /home/tsminst1/tsminst1
errorlogname /home/tsminst1/tsminst1/tsmdbmgr.log
nodename $$_TSMDBMGR_$$
5.
Stop and start the database instance:
1. Stop DB2:
db2stop
2. Start DB2:
db2start
6.
Set the API password:
1. Ensure that the Tivoli Storage Manager server is started. See
Starting the server on AIX, HP-UX, Linux, and Sun Solaris systems for the
details.
2. Log in using the root user ID.
3. Source the database manager by running the following command.
Important: Sun Solaris operating systems Switch to the Korn shell
(/bin/ksh) before running the following command.
. /home/tsminst1/sqllib/db2profile
4. Change the API password, using this command:
/home/tsminst1/sqllib/adsm/dsmapipw
5. When prompted by the dsmapipw command, specify TSMDBMGR as both the
original and new password.
6. Enter this operating system command:
rm /home/tsminst1/tsminst1/tsmdbmgr.log
The database manager and the Tivoli®
Storage Manager API must be configured so that the database manager can back up
the server database.
The
configuration is completed for you automatically if you use the upgrade wizard
(dsmupgdx).
If you do not use the wizard, you must
complete the configuration manually.
Post Implementation Steps
==============================
Verifying access to storage pools on disk
For all disk space that was used for
storage pools (device types of FILE or DISK) by the V5 server, verify that the
user ID that owns the upgraded
Tivoli® Storage Manager server instance has
ownership or read/write permission.
Starting the server instance after the
upgrade
==================================================
Verify that the server instance is
correctly set up by starting the server instance.
Remember: Starting the server is an
operating system-level operation and has certain restrictions.
If you do not have the permissions to use
the DSMSERV program, you cannot start it. If you do not have authority to read
or write files in the
instance directory, you cannot start that
instance of the server.
*
AIX operating systems
You can start the server when logged in to the system with the user ID
that you created for the server instance.
You
can also start the server instance when logged in as the root user.
Registering licenses
=======================
Immediately register any Tivoli® Storage
Manager licensed functions that you have purchased so that you do not lose any
data after you
begin using the server. Use the REGISTER
LICENSE command for this task.
Backing up the database after upgrading the
server
====================================================
After successfully upgrading the server,
perform a full backup of its database as soon as possible. Before performing
the backup, you must first select the device class for backups of the database.
1.
Complete the following steps:
1. If you did not use the upgrade wizard (dsmupgdx) to upgrade the
server, ensure that you have completed the steps to manually configure the
system for database backups.
2. If you used the media method for upgrade and used a tape device,
remove or check out from the library the tape that was used to hold the
extracted data. Prevent the tape from being reused until you are sure that the
upgraded server is running properly and you do not need to repeat the database
insertion step.
2.
Select the device class to be used for automatic backups of the database. Issue
the following command from a IBM® Tivoli® Storage Manager administrative
command line.
set dbrecovery device_class_name
The device class that you specify is used by the database manager for
all automatic database backups.
3.
Back up the database.
backup db devclass=device_class_name type=full
The device class can be the same as or different from the device class
that you specified with the SET DBRECOVERY command. If the device class is
different, you receive a warning message, but the backup operation continues.
Verifying the upgraded server
================================
Verify the operation of the server. If the
server was installed on a new system as part of the upgrade, check and update
connections to storage devices and other components.
1.
Monitor the messages that the server issues as it starts. Watch for error and
warning messages.
2.
If the server is running on a new system as a result of the upgrade, check the
following items:
1. Ensure that all of the original server's storage devices are
accessible to the upgraded server.
2. Compare the device names on the new system with the names for the
devices on the original system. Update definitions for the devices on the
server if needed. For example, update path definitions.
3. Update the network address that is used by backup-archive clients,
storage agents, library client servers, and other servers for communicating
with the upgraded server.
Optionally, instead of making these updates, consider whether you can
use the network address of the original system as the address of the new
system. You might also be able to update domain name service (DNS) to point to
the new system instead of the original system. Consult your network
administrator.
3.
Verify that you can connect to the server using an administrative client as you
did for the earlier version of the server.
4.
Run commands to get a summary of information in the database. Compare the
summary with the results for the same commands before the upgrade.
5.
Perform backups for typical client nodes and verify that the backups work as
expected.
6.
Verify that operations such as LAN-free data movement and library sharing work
correctly.
7.
After you are satisfied that the server is performing as expected and you will
not need to revert to the previous version of the server, remember to return
any settings that you changed to prepare for the upgrade back to the original
values.
Updating automation
===============================
After an upgrade, administrative schedules
that were defined in V5 might not work without modification because of changes
in command syntax. Implement and verify changes to any automation or scripts
that were identified as needing modification in the planning process.
Important: Ensure that automation includes
a backup of the database. Back up the database at least once per day.
Monitoring the upgraded server
=================================
When you start using the upgraded server in
production operation, monitor the space used by the server to ensure that the
amount of space is adequate. Make adjustments as needed.
1.
Monitor the active log, to ensure that the size is correct for the workload
that is handled by the server instance.
When the server workload is up to its typical expected level, and the
space that is used by the active log is 80 - 90% of the space that is available
to the active log directory, you might need to increase the amount of space.
Whether you need to increase the space depends on the types of transactions in
the server's workload, because transaction characteristics affect how the
active log space is used.
The following transaction characteristics can affect the space usage in
the active log:
* The number and size of files in backup operations
o Clients such as file servers
that back up large numbers of small files can cause large numbers of
transactions that complete during a short period of time. The transactions
might use a large amount of space in the active log, but for a short period of
time.
o Clients such as a mail server
or a database server that back up large chunks of data in few transactions can
cause small numbers of transactions that take a long time to complete. The
transactions might use a small amount of space in the active log, but for a
long period of time.
* Network connection types
o Backup operations that occur
over fast network connections cause transactions that complete more quickly.
The transactions use space in the active log for a shorter period of time.
o Backup operations that occur
over relatively slower connections cause transactions that take a longer time
to complete. The transactions use space in the active log for a longer period
of time.
If the server is handling transactions with a wide variety of
characteristics, the space that is used for the active log might go up and down
by a large amount over time. For such a server, you might need to ensure that
the active log typically has a smaller percentage of its space used. The extra
space allows the active log to grow for transactions that take a very long time
to complete, for example.
2.
Monitor the archive log to ensure that space is always available.
Remember: If the archive log becomes full, and the archive failover log
becomes full, the active log can become full and the server will stop. The goal
is to make enough space available to the archive log so that it never uses all
its available space.
You are likely to notice the following pattern:
1. Initially, the archive log grows rapidly as typical client-backup
operations occur.
2. Database backups occur regularly, either as scheduled or done
manually.
3. After full database backups occur, log pruning occurs automatically.
The space used by the archive log decreases when the pruning occurs.
4. Normal client operations continue, and the archive log grows again.
5. Database backups occur regularly, and log pruning occurs as often as
full database backups occur.
With this pattern, the archive log grows initially, then decreases, then
might grow again. Over a period of time, as normal operations continue, the
amount of space used by the archive log should reach a relatively constant
level.
If the archive log continues to grow, consider taking one or both of
these actions:
* Add space to the archive log. This might mean moving the archive log
to a different file system.
* Increase the frequency of full database backups, so that log pruning
occurs more frequently.
3.
If you defined a directory for the archive failover log, determine whether any
logs get stored in that directory during normal operations. If the failover log
space is being used, consider increasing the size of the archive log. The goal
is that the archive failover log is used only under unusual conditions, not in
normal operation.
Backoutplan
==================
Reverting from V6.2 to the previous V5
server version
====================================================
If you need to revert to the previous
version of the server after an upgrade, you must have a full database backup
from your original version, the server installation media for your original
version, and key configuration files. By carefully following the preparation
steps before upgrading the server, it might be possible to revert to the
previous version of the Tivoli® Storage Manager server with minimal loss of
data.
You must have the following items from the
earlier version of the server:
*
Server database backup
*
Volume history file
*
Device configuration file
*
Server options file
* The dsmserv.dsk file
The value of the REUSEDELAY parameter for
storage pools compared to the length of time that you were running the V6.2
server can affect whether client data is affected by reverting to the earlier
server version.
Steps for reverting to the previous server
version
----------------------------------------------------
1.
Back up the V6.2 database and save the contents of the instance directory,
including the volume history file, the device configuration file, and server
options file. Keep these files in case you need to return to the V6.2 version
of the server.
2.
Remove the database from the database manager, then delete the database and
recovery log directories.
1. Manually remove the database. Issue the command:
dsmserv removedb tsmdb1
You can also use the following command to remove the database:
db2 drop db tsmdb1
2. If you need to reuse the space that is occupied by the database and
recovery log directories, you can now delete these directories.
3.
Use the installation program to uninstall the V6.2 server. Uninstallation
removes the server and the database manager code, with their directories.
See Uninstalling Tivoli Storage Manager for details.
4.
Reinstall the version of the server program that you were using before the
upgrade to V6.2. This version must match the version that your server was
running when you created the database backup that you will restore in a later
step.
For example, if the server was at version 5.4.4.0 before the upgrade,
and you intend to use the database backup that was in use on this server, you
must install the V5.4.0.0 server program and then the V5.4.4.0 fix pack to be
able to restore the database backup.
1. Reinstall the base version of the server that was in use before the
upgrade to V6.2.
2. Reinstall any fix packs that had been installed on the base server
version before the upgrade to V6.2.
5.
Copy the following files, which were backed up before the upgrade of the
original server, to the directory for server information.
* Device configuration file
* Volume history file
* The dsmserv.dsk file
* The server options file (typically dsmserv.opt)
6.
Format the database by using the DSMSERV FORMAT utility. For details see the
information for the version of the server that you are reinstalling.
Information for V5.5 is available at this information center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1
Information for V5.4 and V5.3 is available
in the same information center. In the navigation pane, scroll down and expand
Previous versions.
7.
Restore the database using the backup that was created in the preparation steps
before the upgrade.
8.
If you enabled data deduplication for any FILE-type storage pools that existed
before the upgrade, or if you moved data that existed before the upgrade into
new storage pools while using the V6.2 server, you must perform additional
recovery steps. See Additional recovery steps if you created new storage pools
or enabled data deduplication.
9.
If the REUSEDELAY setting on storage pools was less than the age of the
database that you restored, then restore volumes on any sequential-access
storage pools that were reclaimed after that database backup. Use the RESTORE
VOLUME command.
If you do not have a backup of a storage pool, audit the reclaimed
volumes using the AUDIT VOLUME command, using the FIX=YES parameter to resolve
inconsistencies. Use the command:
audit volume volume_name fix=yes
10.
If client backup or archive operations were performed using the V6.2 server,
you might need to audit the storage pool volumes on which the data was stored.
11.
If you were using active-data pools before upgrading to V6.2, you must recreate
them after reverting to the earlier version of the server.
The amount of time required to recreate the active-data pools might be
significant, depending on the number and size of the active-data pools to be
recreated.
No comments:
Post a Comment