There is a way to start a backup from the TSM server itself, and that is by defining a client action. For example, to start an incremental backup on a node, run:
define clientaction action=incremental
You can use wild cards like * in the node name, for example:
def clienta node* act=i
You can monitor the schedule event, using the following command:
q ev * @1
You may cancel this schedule, by running:
delete schedule @1
The following command can be used to tail the TSM console log:
This will allow you to continously follow what is happening on the TSM server.
To save the complete configuration of a TSM server to a file, run:
dsmadmc -id=admin -password=admin show config > /tmp/config
This assumes that you have an admin account with the password admin. And it will write the output file to /tmp/config.
If you wish to have comma separated output, add -comma.
To just display the status of the TSM server, run (this is included in the output of show config):
To register a new TSM admin, run:
register admin adminname password contact="Contact details of the new admin" email@example.com
Next, grant system privilege authority to the new admin:
grant authority adminname class=sys
To remove a TSM admin, run:
remove admin adminname
If you need to exclude a specific file system from the TSM backup, than you would add the following line to the dsm.sys file:
DOMAIN ALL-LOCAL -/opt/archive
This examples will avoid backing up file system /opt/archive.
Now, what if you wish to exclude a certain directory within a file system from the backup:
Create the following enty in the dsm.sys file:
Then create the inclexcl file and add the following line:
This will only exclude the tmp folder in file system /opt/archive.
You can check with the following command:
# dsmc q inclexcl
How do you test if Oracle TDP (RMAN) is working properly?
# tdpoconf showenv
If you have a TSM database spread across mutliple database volumes on disk, be very careful on how you use them. It is best to assign multiple database volumes on different disks, all equal in size. This way, TSM is able to use the
performance of several disks equally.
Also, take a look at the assigned capacity of the TSM database. It might well be that not the full capacity of the database is assigned to TSM; this way, some database volumes are more heavily used than other.
q dbv f=d
q db f=d
These commands can be used to find out, how your database capacity is assigned. If it isn't fully assigned, then do it now.
Check the output of the TSM commands with the location of your database volumes on the operating system, to see if the database volumes are equally spread across multiple disks. The AIX commands iostat
will give you a good idea if your disks are used equally.
When using TSM on AIX, JFS file systems for storage of the database volumes are preferred, and not RAW logical volumes. This subject usually tends to cause discussion, so here are the reasons for using JFS and not use RAW logical volumes:
When TSM has JFS files open, they are locked by JFS and other applications cannot write to them. However, raw logical volumes are not locked and any application can write to them. TSM tries to prevent starting more than one instance of the same server from the same directory, but it can be done. If you are using raw logical volumes, multiple server instances can simultaneously update the same information. This could cause errors in the database, recovery log, or storage pool raw logical volumes. Auditing a corrupted TSM database and fixing corruptions can take up to a day downtime.
After a database, recovery log, or storage pool volume is defined to TSM, you cannot change its size. TSM uses size information to determine where data is placed and whether volumes have been modified by other applications or utilities. However, if you use raw logical volumes, smit lets you increase their sizes. If the volume is defined to TSM before its size is increased, TSM cannot use the volume or its data.
The use of JFS file systems for database, recovery log, and storage pool volumes requires slightly more CPU than is required for raw volumes. However, JFS read-ahead caching improves performance. Lab tests have proven that the use of raw logical volumes tend to give better performance. So as long as you have enough CPU, you may still use JFS.
How many times can the tape drives be cleaned?
# mtlib -l /dev/lmcp0 -qL
Look for "avail xxxx cleaner cycles" at the bottom.
Which cleaning tapes are in the library?
# mtlib -l /dev/lmcp0 -qC -s FFFD
The first column in the output is the volume serial number of the cleaning tapes.
When was the cleaning tape last used?
# mtlib -l /dev/lmcp0 -qE -V [tape-volume-serial-number] -u
Look for "last used" at the bottom of the output.
How are my tape drives doing (from a TSM viewpoint)?
# dsmadmc -c comma -id=readonly -password=readonly q dr f=d
Look for "On-Line" and "Drive State" in the output. Also check if the paths to your tape drives are on-line.
# query path
Want to know what all TSM administrators did in the last 24 hours in TSM?
# dsmadmc -comma -id=readonly -password=readonly query actlog s=ANR2017I begind=-1 begint=09:00 endd=today endt=09:00 | grep -v -i readonly
This assumes you have an administrator account configured, known as readonly
with password readonly
, which has no privileges.
This command will show you all administrator actions from 9 AM yesterday until 9 AM today.
Number of results found for topic TSM
Displaying results: 1 - 10.