3.1 TSM V7 Database and recoverylog overview and functions

 TSM V7.1 Database and Recoverylog Overview & Functions

The server uses the Tivoli Storage Manager database to manage information about client files. The Tivoli Storage Manager recovery log ensures that the database is consistent and available. Starting from TSM V6, DB2 database is used for server transactions.

Tivoli Storage Manager Database (DB2)

The Tivoli Storage Manager database contains information that is needed for server operations and information about client data that is backed up, archived, and space-managed. The database does not store client data. Instead, the database points to the locations of the client files in the storage pools. The database includes the following information

• Client nodes and administrators

• Policies and schedules

• Server settings

• Locations of client files on server storage

• Directory structures

• Server operations, for example, activity logs and event records

If the database is unusable, the entire Tivoli Storage Manager server is unavailable. If the database is lost and cannot be recovered, all of the data that the server manages is lost. Therefore, it is imperative that the server and database are protected.

After you install a new server or upgrade an existing database, you run an offline utility command to initialize the database and recovery log. You run DSMSERV FORMAT for a new server. You run DSMSERV LOADFORMAT when upgrading to a new database. Both of these utilities initialize the active and archive logs and optionally initialize the archive fail over log and mirror of the active log.

Tivoli Storage Manager V7 database features

Automatic statistics collection: Automatic statistics collection helps to improve database performance by collecting up-to-date table statistics.

Automatic database reorganization: Automatic reorganization of the database tables is done based on the statistics gathered.

SQL queries: You can get information from the server database with full-function SQL queries. The database makes more sophisticated SQL queries on the data possible. To use some of the capabilities, you might require more advanced SQL skills to develop new tools.

Database audits: Audits on the database run automatically as needed to ensure consistency. Separate audits that might be long-running are not needed.

Database buffer size: The database manager automatically adjusts the values for several memory configuration parameters that are based on requirements of the workload of the system.

Note:

• You can continue to manage the server database by using Tivoli Storage Manager administrative interfaces. You do not require the skills of a database administrator.

• Although the Tivoli Storage Manager database is running on DB2, it is designed especially for Tivoli Storage Manager.

• You need to manage the database with Tivoli Storage Manager utilities. If you have DB2 experience, you can use DB2 utilities to only monitor the database.

• Do not alter the DB2 software that is installed with Tivoli Storage Manager installation packages and fix packs. Do not install or upgrade to a different version, release, or fix pack of DB2 software because doing so can damage the database.

• The TSM server requires that you install and use the DB2 V10.5 that is packaged with the Tivoli Storage Manager server. No other version of DB2 can exist on the system.

From TSM V7, TSM has DB2 version 10. The DB2 V10.x database for Tivoli Storage Manager manages information about client files located in storage pools and provides for the other server components. The database contains, among other things

• Access control information for administrative clients

• Information about registered client nodes

• Policies and schedules

• The activity log and event records

• Information about Tivoli Storage Manager volumes

• Data storage inventory

• Encryption key

• Deduplication index

• Disaster recovery plans

Tivoli Storage Manager Recovery log

The recovery log helps ensure that a sudden failure does not leave the database in an inconsistent state. The recovery log is also necessary for restoring the database. All changes to the database since the last database backup are saved in the recovery log. With roll-forward mode and an intact recovery log, you can recover the database up to its most current state, the point at which the database was lost. The recovery log keeps all transactions since the last database backup. Frequent database backups reduce recovery log storage requirements. After a full backup finishes, recovery log records that precede the backup are deleted.

The recovery log consists of the following logs

Active log: The active log stores all the transactions that are not yet committed. The active log always contains the most recent log records.

Archive log: The archive log is a closed and stored copy of the previous active log. Archived log files are stored until they are included in a database backup. This log is not needed for normal processing, but it is needed to recover the database.

Archive failover log: The archive failover log is the directory that the server uses to store archive log files that cannot be stored in the archive log directory.

Log mirror: The log mirror is a duplicate copy of the active log. All changes that are made to the active log are also written to the log mirror. Having the log mirror for the active log can protect the database from a hardware failure that affects the active log. Place the log mirror on a different physical device.

Changes to the database are recorded in the recovery log for maintaining a consistent database image. The recovery log includes updates to information that can include the following activities

• Defining a management class

• Backing up a client file

• Registering a client node

For the best availability and protection, you can specify that active logs are mirrored. You should locate those mirror logs on a separate physical device.

Monitoring the Database and Recovery log

• Monitor the database and log space and the file systems where the directories are located to ensure that space is always available.

• Use the QUERY DB command to examine information about the database.

• Use the QUERY DBSPACE command to view information about the storage space defined for the database, such as total space, used space, and free space.

• Use the format=detail parameter to show more detailed information.

• Use the QUERY LOG command for obtaining information on the log. The same information is available when the Tivoli Storage Manager server is offline. Issue the DSMSERV DISPLAY LOG command.

Tivoli Storage Manager Transaction

A transaction is the unit of work exchanged between the Tivoli Storage Manager client and Tivoli Storage Manager server. The server holds transaction log records in a buffer pool until they are written to the recovery log to support multiple transactions from concurrent client sessions. When the transaction is committed.The log records that transaction to the active recovery log, then the  Tivoli Storage Manager database is updated.

Tivoli Storage Manager provides a TXNGROUPMAX server option. Use this option to specify the number of files or directories that are contained within a transaction group. The default option is 4096 objects.

Changes resulting from transactions are in the buffer pool temporarily and not made to the database immediately. Therefore, the database and recovery log are not always consistent. When all records for a transaction are written to the recovery log, Tivoli Storage Manager updates the database. The transaction is then committed to the database. At some point after a transaction is committed, the server deletes the transaction record from the recovery log.

When a transaction occurs, the Tivoli Storage Manager server does the following actions

• Reads a database page into the database buffer and updates it. A page is a 16 KB block that is transferred as a unit between memory and disk storage.

• Writes a transaction log record to the recovery log to describe the action that is occurring and associates it with the database page. This action is a precaution in case the database page needs to be rolled back during recovery.

• Writes the database page to the database, releasing it from the buffer pool. The page remains in the buffer pool until buffer space is needed for another page.

• A transaction containing more than one file or directory is a transaction group. Tivoli Storage Manager provides a TXNGROUPMAX server option that lets you specify the number of files or directories that a transaction group contains. You can affect the performance of client backup, archive, restore, and retrieve operations by using a larger value for the TXNGROUPMAX option.

• You can use the TXNGROUPMAX option to increase performance when Tivoli Storage Manager writes to tape. This performance improvement can be considerable when a user transfers multiple small files.

• Be sure to monitor the effects on the recovery log if you increase the value of TXNGROUPMAX by a large amount. The larger value can increase utilization of the recovery log, and increase the length of time for a transaction to commit.

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

3.2 Monitoring and Managing TSM V7 Database and Recovery log space usage

How to monitor the TSM V7 Database and Recovery log

1) You have to create and designate directories or drives that the server uses for the database during TSM Server instance configuration. Afterward, the database manager, which is part of the server, automatically manages the space available to the directories as database space.

2) Locate the database on fast reliable storage, such as Redundant Array of Independent Disks (RAID) hardware. Do not place the database in directories that might run out of space. Locate the directories across different physical devices (separate LUNs).

3) Database size is determined by the amount of data that you store. The Database Manager manages the database space automatically. The maximum supported limit is 4 TB. Use the QUERY DBSPACE command to monitor database space usage. The size of the database depends on the following factors

• The number of client files to store

• The number of versions of backed up files that are kept

• Whether you use caching

4) Caching option is available in the disk storage pool. When cache is enabled, the migration process leaves behind duplicate copies of files after the server migrates these files to the next storage pool in the hierarchy. Consider using Active Data Pools instead

5) There are both advantages and disadvantages of enabling cache on disk pools. You need to cheese this option according to your resources. Using cache can improve the speed with which the server retrieves some files. Consider enabling cache for space-managed files that clients frequently access. If space is needed to store new data in the disk storage pool, cached files are erased and the space is used for those new files.

• Using cache can require more space for the server database because the server maintains two copies of the file.

• If you want to use caching, you cannot also enable shredding for that disk storage pool.

TSM Database size estimation:

The size of your Tivoli Storage Manager database depends on the number of client files to store and how Tivoli Storage Manager manages them. If you can estimate the maximum number of files that might be in server storage at any time, you can use the following information to come up with a useful database size estimate

• Each version of a file that Tivoli Storage Manager stores requires about 400 to 600 bytes of database space.

• Each cached or storage pool copy of a file requires about 100 to 200 bytes of database space. Caching is turned off by default. It is used only to move from one storage pool to next.

• Overhead can increase the required space by an additional 50%.

Maximum and Minimum size allowed for Database and Recovery log

Database

• Minimum size: 2.2 GB

• Maximum size: 4 TB

Consider restore time when deciding how large the database should be. 

Active log

• Minimum size: 2 GB

• Maximum size: 128 GB

• Default size: 16 GB

Active log space requirements increase when you use data deduplication. 

Archive log

• Large enough to contain the logs that the previous full backup generates

• Cleared only in the case of a full backup

Example for Database estimation 

• Backed up objects

50,000,000 objects might be backed up. Storage policies call for retaining up to three copies of backed up files. 150,000,000 stored backed up objects.

• Archived objects

10,000,000 objects might be archived copies of client files.

• Space-managed objects

20,000,000 objects migrated from client workstations might be in server storage. [(50,000,000 X 3 ) + 10,000,000 + 20,000,000)] x 600 bytes = 100 GB

• Copy storage pool objects - All primary storage pools are backed up to the copy storage pool:

(150,000,000 + 10,000,000 + 20,000,000) x 200 bytes = 34.3 GB 

• Active-data pool objects - All the active client backup data in primary storage pools is copied to the active-data pool. 

Assume that 50,000,000 versions of the backup files in the primary storage pool are active.

50,000,000 x 200 bytes = 9.5 GB

Estimated database size: 144 GB + overhead (up to 50%) = approximate 216 GB

In the above example, the computations represent probable maximums. The numbers are not based on the use of file aggregation. In general, the more that small files are aggregated, the less database space that is required.

If you cannot estimate the numbers of files, you can roughly estimate the database size as 1% to 5% of the required server storage space. For example, if you need 1,000 GB of server storage, make your database between 10 GB and 50 GB.

Increasing the TSM V7 Database Size

1) You can add directories to the database by using the EXTEND DBSPACE command. The updates for this operation include distributing data across all database directories and the reclaiming of unused space and returning it to the system. Because redistribution operations take considerable system resources, plan ahead when you want to add space to the database. For example

      extend dbspace e:\tsm_db\dbs7 on Windows

      extend dbspace /tsmdb/dbs7 on UNIX

The directories must be empty and accessible to the user ID of the database manager.

2) DSMSERV EXTEND DBSPACE, can be used to perform the same function as the EXTEND DBSPACE command, while the server is offline.

3) You should run the EXTEND DBSPACE commands while the server is not handling a heavy load.

4) You can also reduce or remove database directories if they are not required by using REMOVE DB command

Increasing the TSM V7 Activelog size

If the log is running out of space, the current transaction is rolled back, and the server issues an error message and halts. You cannot restart the server until you increase the active log size. If you use the active log mirror, it will also increases to the new size. You can increase the size of the active log by completing the following steps

• Issue the DSMSERV DISPLAY LOG offline utility to verify the size of the active log.

• In the dsmserv.opt file, update the ACTIVELOGSIZE server option to the new maximum size of the active log. For example, to change the active log to 120 GB, enter the following server option: 

activelogsize 122880

• If you want to use a new active log directory, update the directory name specified in the ACTIVELOGDIR server option.

• The changes take effect when you restart the server.

TSM Server options to monitor Database and Recovery log

1) You can use server options to control some aspects of database processing. They are available during and after installation. The following database options are specified in the server options file during installation:

• ACTIVELOGDIR

• ACTIVELOGSIZE

• ARCHLOGDIR

• ARCHFAILLOGDIR

• MIRRORLOGDIR

• DBMEMPERCENT

2) The ACTIVELOGDIR, ACTIVELOGSIZE, ARCHLOGDIR, ARCHFAILLOGDIR, and MIRRORLOGDIR options control the location and size of the logs and mirrors. These options are set during initial configuration. 

3) DBMEMPERCENT is the percentage of system memory that is dedicated to the database. If DBMEMPERCENT is not specified, the default is applied, which is 70% - 80%.

4) You can use server options to control how Tivoli Storage Manager groups and transfers data. Several of these options pertain to the size of the transaction and you can use them for improving performance. Group options include the following items.

• MOVEBATCHSIZE: Specifies the number of files to move and group in a batch, within a transaction (Default is 1000 files).

• MOVESIZETHRESH: Specifies the threshold for the amount of data to move as a batch, within the same server transaction (Default size is 4096 MB).

• TXNGROUPMAX: Specifies the number of files to transfer as a group between a client and the server between transaction commit points (Default is 4096 objects.)

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

3.3 Taking Tivoli Storage Manager V7 database backup

 Importance of backing up the Tivoli Storage Manager V7 database

Without the database, you cannot back up or restore your data, so you should take the TSM database backup in regular intervals in order to secure the TSM infrastructure. Backing up the TSM database with a daily automated schedule or manually as needed, ensures the Tivoli Storage Manager environment can function correctly.

The TSM database holds all the transaction information, such as the node data backup locations. When the TSM database is backed up, the recovery log is also backed up. Without the database and recovery log, node data cannot be restored.

Other metadata stored in the TSM database including defined schedules, policy definitions, and server settings are also required for TSM server operations. Without this information, the server cannot function.

Prerequisites for TSM V7 database backups

1) Starting TSM V6, you should use the set dbrecovery command to specify the device class to use for database backups

set dbrecovery <name of device class for database backup>

Example: set dbrecovery dbbackup

2) If you do not use the set dbrecovery command before the first database backup runs, the backup fails. You only need to use the set dbrecovery command when you have a new device class.

3) If you perform a database backup and use a device class other than the one that you specified in the set dbrecovery command, an error message occurs, but the backup still runs and finishes successfully.

Taking a TSM V7 database backup

The first database backup is always a full backup. Backups of the database are scheduled as part of a scripted daily server maintenance process. Only full database backups empty the archive log. To back up the Tivoli Storage Manager database to sequential media, use the following command

backup db devclass=<devcname>

Taking TSM V7 database backup through Operations Center

Step 1: In the servers table, select a server and choose Back Up action.

Step 2:

• In BackUp Database dialog, choose backup type, full or dbsnapshot, and choose an available device class on which the data is backed up.

• If you want to set the selected deviceclass to be the default deviceclass for next backup action, you may want to check the checkbox below.

• Click BackUp button to start backup progress.

Step 3: TSM Operations Center shows the database backup task started. You can choose

the Close & View Tasks to view backup result.

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

4.1 IBM TSM V7 Storage Pools Overview and Introduction

Tivoli Storage Manager Storage Pools Overview and Functions

A storage pool is a named set of volumes that belongs to the same device class, which is the destination of backed up or archived data. A device class is a grouping of like devices, such as disk or tape.

The purpose of storage pools is matching user requirements for data with the physical characteristics of storage devices. For example, if you need immediate access to certain data, you can define a storage pool that consists of storage volumes on high-performance disks. You can associate this storage pool as a destination for files by binding the appropriate management class.

Files can be placed initially on different storage pools according to the stated storage management policy. Files are then moved automatically to other devices to adhere to free space, space utilization, performance, and recovery requirements.

A storage destination identifies the storage pool where client data goes when it is backed up, archived, or migrated. The management class, which is a part of policy management, includes the backup and archive copy group definitions. These definitions specify the storage destination. 

An administrator with system, storage, or operator privilege can manage data storage, including the planning, preparing, monitoring, and deleting of storage volumes and storage pools. The tasks depend on the level of the privilege class.

TSM Storage Pools Features

• They are a collection of like media, same device class.

• Provide storage for backed up, archived, or migrated files.

• Support a variety of devices.

• You can chain them together to create storage hierarchy.

• Stores data in defined storage pool volumes.

• First, client sends data to server

• Server writes data to disk pool

• Moves data from disk pool to the next defined storage pool

• Server records data storage information in Tivoli Storage Manager database

Types of Storage Pools 

There 3 types of storage pools in Tivoli Storage Manager

Primary Storage Pool: It is the first destination of client backups. It can either Disk, Tape or FILE device class.

Copy storage pool: Backup copies of active and inactive data from primary storage pools for off-site storage. Copy storage pools contain backups of the primary storage pools. You can backup storage pool data to disk, which uses a file device class, or removable media, such as tape.

Active-data pools: Backup copies only of active data for fast restoration of client data. Active-data pools only contain the latest, or active version of data. Use them in the following situations

• With sequential-access disk (FILE)

• With sequential-access tape or optical

• To collocate active versions of backup data

• For backup data only, not for archive or HSM data

• With the disaster recovery manager

Defining storage pools

During TSM Server installation, Tivoli Storage Manager provides the following predefined random access storage pools

• BACKUPPOOL: A storage destination for user files that are backed up to the server

• ARCHIVEPOOL: A storage destination for user files that are archived to the server

• SPACEMGPOOL: A storage destination for files that are migrated from user nodes.

Example:

define stgpool testpool disk description="test storage pool" maxsize=5m highmig=70 lowmig=30 cache=yes nextstgpool=destpool

Defining a primary & copy storage pool:

Use the following command to define a primary storage pool

DEFine STGpool poolname devclass 

For example: DEFine STGpool tapepool devclass=tape

For a copy storage pool, you need to specify the pool type. Use the following command to define a copy storage pool

  DEFine STGpool poolname devclass pooltype=copy

For example: DEFine STGpool copy1 devclass=tape pooltype=copy

Updating and querying storage pools

Use the update stgpool command to change any parameter in an existing primary, copy, or active-data storage pool. If you do not explicitly update a parameter, it remains unchanged. The parameters to update are the same as the parameters that are defined for a storage pool. 

UPDate STGpool poolname

Use the query stgpool command to show information about one or more storage pools.

Query STGpool poolname

The query occupancy command shows the following information

• Node name

• Type, backup, archive, or space managed

• File space name and number

• Storage pool names

• Number of files

• Physical and logical space occupied

Query OCCupancy nodename

Overflow location for the storage pool media

Use database tracking to change the location of a volume to a specified overflow location. The Tivoli Storage Manager administrator uses overflow storage pools to better manage storage pools that grow beyond the capacity of the library. Database tracking is used primarily for long-term archive storage pools where the data is maintained on-site but is rarely retrieved for Tivoli Storage Manager processing.

The first stage in implementing an overflow storage pool is defining the location of the volumes when they overflow from the library. You can define the location by using either the define stgpool or update stgpool command and the OVFLOCATION parameter. This parameter is a text description of where the volumes are found. 

UPDate STGpool tapepoolpool ovflocation=locker100

The second step is moving the media to the overflow location. Issue the move media command, which moves media from the library to the overflow location. For example, to move all full volumes in the specified storage pool out of the library, use the following command

move media * stgpool=tapepool

You can show the overflow location for a storage pool by using the query stgpool f=d (format=detail) command. This command produces output that shows the storage pool name, type, associated device class, estimated capacity, and the overflow location. The overflow location has the following attributes

• A physical location, defined with the MOVE MEDIA command

• Used when library becomes full

• Applicable to primary or copypool volumes

• Associates the location of volumes outside of the library

• You must move volumes to the overflow location manually   

Backing up primary storage pools

We use copy storage pools for taking backup of primary storage pools. Copy storage pool media are send to offsite for Disaster recovery purposes. To backup a primary storage pool to a copy pool, use the following command

BAckup STGpool primary_pool_name copy_pool_name

If a file already exists in the copy storage pool, the file is not backed up unless the copy of the file in the copy storage pool is marked as damaged. However, a new copy is not created if the file in the primary storage pool is also marked as damaged. In a random-access storage pool, neither cached copies of migrated files nor damaged primary files are backed up. 

Deleting storage pools and volumes

You can delete the storagepools at anytime if you no longer need them. You first have to delete all the volumes assigned to that storagepool before deleting any storagepool.

delete stgpool tapepool

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

4.2 TSM V7 Storage Pool Volumes Overview and Features

Tivoli Storage Manager Storage pool volumes

A volume is the basic unit of storage for Tivoli Storage Manager storage pools. Tivoli Storage Manager volumes can be mainly classified according to status: private & scratch volumes.

A private volume is a labeled volume that is in use or owned by an application, and may contain valid data. You must define each private volume.

A scratch volume is a labeled volume that is empty or contains no valid data and that can be used to satisfy any request to mount a scratch volume. When data is written to a scratch volume, its status is changed to private, and it is defined as part of the storage pool for which the mount request was made. When valid data is moved from the volume and the volume is reclaimed, the volume returns to scratch status and can be reused by any storage pool associated with the library.

You can use the define volume command to assign a random or sequential access volume to use for storage within an existing storage pool. You can define a volume to either a primary storage pool or a copy storage pool.

For each storage pool, you must decide whether to use scratch volumes. If you do not use scratch volumes, you must define private volumes, or you can use space-triggers if the volume is assigned to a storage pool with a FILE device type.

Tivoli Storage Manager keeps an inventory of volumes in each automated library it manages and tracks whether the volumes are in scratch or private status. When a volume mount is requested, Tivoli Storage Manager selects a scratch volume only if scratch volumes are allowed in the storage pool. The server can choose any scratch volume that has been checked into the library.

You do not need to allocate volumes to different storage pools associated with the same automated library. Each storage pool associated with the library can dynamically acquire volumes from the library's inventory of scratch volumes. Even if only one storage pool is associated with a library, you do not need to explicitly define all the volumes for the storage pool. The server automatically adds volumes to and deletes volumes from the storage pool.

A disadvantage of using scratch volumes is that volume usage information, which you can use to determine when the media has reached its end of life, is deleted when a private volume is returned to the scratch volume pool.

For sequential access storage pools with a device type other than FILE or SERVER, you must prepare volumes for use. When the server accesses a sequential access volume, it checks the volume name in the header to ensure that the correct volume is accessed. 

When you first configure the tape library with TSM server, you need to label and checkin the tapes from the TSM admin console so that TSM can use them for backups.  Prepare the volumes as follows:

• Label the volume

• For storage pools in automated libraries, use the checkin libvolume command to check the volume into the library.

Defining storage pool volumes for disk

To define storage pool volumes for a disk storage pool, use the following command

DEFine VOLume poolname volname Formatsize=Format_size 

For example:

   DEFine VOLume BACKUPPOOL /opt/tsmdata/v7 formatsize=500 

Note: You don't have to define storage pool volumes for FILE and Tape pools, TSM server will automatically assign tapes from library inventory to these storage pools whenever needed. You should use define volume command only if you want to permanently assign certain tapes to certain pools. Volumes defined like this cannot be reused by other storage pools unless you delete them.

Concurrent storage pool volume access

Concurrent access can improve the restore performance because two or more clients can access the same volume at the same time. Multiple client sessions, archive, retrieve, backup, and restore, or server processes, for example, storage pool backup, can read the volume concurrently. In addition, one client session can write to the volume while it is read.

The Tivoli Storage Manager server allows concurrent read- access and write-access to a volume in a storage pool with the device type of FILE. The following server processes have concurrent read access to FILE volumes

• BACKUP DB

• BACKUP STGPOOL

• COPY ACTIVEDATA

• EXPORT/IMPORT NODE

• EXPORT/IMPORT SERVER

• GENERATE BACKUPSET

• RESTORE STGPOOL

• RESTORE VOLUME

The following client sessions can concurrently read and write to FILE volumes

• BACKUP

• RESTORE

• ARCHIVE

• RETRIEVE

The following server processes do not have concurrent access to FILE volumes:

• AUDIT VOLUME

• DELETE VOLUME

• MIGRATION

• MOVE DATA

• MOVE NODEDATA

• RECLAMATION

Deleteing Storage pool Volumes

You can use the delete volume command to delete a volume that is assigned to either a primary or copy storage pool. During the processing of this command for a primary storage pool volume, if Tivoli Storage Manager deletes the primary copy of a file, it also deletes copies of that file that are in copy storage pools. If you delete several volumes, delete the volumes one at a time. Concurrent volume deletion adversely affects server performance.

Before you delete all volumes that belong to the storage pool, change the access mode of the storage pool to unavailable so that no files are written to or read from volumes in the storage pool. To delete an empty storage pool volume, use the delete volume command

DELete VOLume volumename

You cannot delete a volume that contains data unless you specify DISCARDDATA=YES on the delete volume command as follows

DELete VOLume volumename DISCARDData=YES

If archive retention protection is enabled, the data cannot be deleted until the retention period is met. Use the query content command to determine the contents that are stored on a volume by querying a Tivoli Storage Manager database table.

Deleting Storage Pool

Use the delete stgpool command to delete a storage pool. To use this command, you must first delete all volumes that are assigned to the specified storage pool. You cannot delete a storage pool that is defined as a subordinate storage pool. Do not delete a storage pool that is specified as a destination for a management class or copy group in the ACTIVE policy set.

Before you delete a storage pool, delete all volumes in that storage pool. To determine the volumes to delete, query the storage pool with details, and query that storage pool’s volumes. Below are some of the useful commands before deleting storage pool volumes and storage pools.

Query STGgpool pool_name f=d 

Query volume

Query CONtent volumename

DELete VOLume volumename DISCARDData=yes 

DELete STGpool poolname

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

4.3 TSM V7 Device Class Introduction

 Tivoli Storage Manager Device Class Overview

A device class represents a set of storage devices with similar availability, performance, and storage characteristics. Tivoli Storage Manager manages these device types and also uses the device class to determine the device and storage volume type to use. Tivoli Storage Manager uses these device classes to do the following data actions

• Storing backup, archive, or space-managed data, primary storage pools.

• Storing copies of primary storage pool data, copy storage pools.

• Storing database backups.

• Exporting or importing Tivoli Storage Manager data.

Each device that is defined to Tivoli Storage Manager is associated with one device class. The device class specifies the device type and media management information, such as recording format, estimated capacity, and labeling prefixes

For random-access storage, Tivoli Storage Manager supports only the DISK device class. The DISK device class is predefined by Tivoli Storage Manager. However, you can define many storage pools that are associated with the DISK device class. You cannot modify the DISK device class.

You can define additional device classes so that they reflect specific devices, media, and procedures. Use the following command to define additional device classes.

DEFine DEVClass DEVType=type of device

Based on the tape environment, an administrator with system privileges can define as many different device classes for tape storage pools as needed. Each tape device class is uniquely identified by its name. Not all device classes are available on all platforms. You can use tape device classes parameters to control the following information:

• Whether you use cartridge or reel tape (DEVtype).

• The maximum tapes that can be mounted simultaneously (MOUNTLimit)

• The maximum minutes before an idle tape is dismounted (MOUNTRetention)

• The tape volume naming convention (PREFIX)

• The estimated volume capacity (ESTCAPacityy

• The use of compression by the client or tape hardware does not increase capability.

The FILE device type lets you create sequential volumes by creating files on disk storage. To the server, these files have the characteristics of a tape volume. FILE volumes can also be useful when transferring data for purposes such as electronic vaulting or for taking advantage of relatively inexpensive disk storage devices. One device class might be associated with multiple storage pools. Each storage pool is associated with only one device class. Each device class is characterized by its device type, which indicates the type of storage volumes that are used to store data.

Tivoli Storage Manager device drivers

The Tivoli Storage Manager device driver that Tivoli Storage Manager supports are

IBM device drivers: atape on AIX, IBMTape on Windows, Atdd on HP, which are required for some devices. If a device requires an IBM device driver, it is noted next to the device name. 

If the tape library is non-IBM, then you should use TSM SCSI device drivers instead of their own device drivers.

Supports third-party vendor device drivers if they are supplied by the hardware vendor and are associated with the GENERICTAPE device class.

Device class and storage pool

Each device is associated with a device class that specifies the device type and how the device manages the media. If you have two libraries, you need two device classes. Storage pools are mapped to a device class. Through this mapping, when data is written to, or accessed from, a storage pool, Tivoli Storage Manager is able to access it. If the device is not listed on the IBM support page, it is not supported.

Watch below video to learn how to define FILE device class and storage pools

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]

5.1 How to monitor and manage TSM migration process ?

What is Migration Process in TSM V7

Automatic data movement between storage pools balances the performance and cost of different storage devices while ensuring adequate free space to meet new space allocations. This process is known as migration. 

For each storage pool, you define low and high migration thresholds. Migration thresholds are based on a percentage of the storage pool’s total data capacity. The low threshold identifies the amount of free space needed to meet the daily processing requirements of your business. The high threshold triggers migration and ensures that enough free space is available while migration occurs. The difference between the high and low thresholds indicates the approximate amount of data that is migrated.

Ensure that the amount of data that is migrated from a disk storage pool is a multiple of the capacity of a tape volume in the next storage pool. This policy helps reduce tape mounts and uses the space on tape volumes effectively. 

Storage pools are chained to form a storage hierarchy. The data flows to the next designated storage pool in the chain. When the high threshold is reached, files migrate to the specified next-in- chain storage pool. Migration ends when the amount of occupied space in the storage pool declines to the low migration threshold. Migration does not occur if there is no next storage pool.

How Migration process works ?

1) Tivoli Storage Manager first identifies the client node that has backed up or migrated the largest single file space or has archived files that occupy the most space. When the server identifies that client node, the server migrates all files from every file space belonging to that client. The migration applies to those files if the number of days in the storage pool exceeds the value that the MIGDELAY parameter specifies.

2) After the files for the first client node migrate to the next storage pool, the server checks the low migration threshold for the storage pool to determine if the migration process should stop. If the amount of space that the storage pool uses is now below the low migration threshold, migration ends. If not, using the same criteria, Tivoli Storage Manager chooses another client node, and the migration process continues.

3) If the value for the MIGCONTINUE parameter is set to YES, Tivoli Storage Manager continues the migration process based on how long the files are in the storage pool. The oldest files are migrated first until the low migration threshold is reached. If the value for the MIGCONTINUE parameter is set to NO, the migration process ends, and the administrator receives a warning message.

4) If multiple migration processes are running, controlled by the MIGPROCESS parameter of the define stgpool command, the files for more than one node might be chosen for migration at the same time.

5) If the cache option is enabled, files that are migrated remain on disk storage, that is, the files are cached, until space is needed for new files. You can enable caching by specifying CACHE=YES when you define or update a disk storage pool. When caching is enabled, the migration process leaves behind duplicate copies of files on disk after the server migrates these files to subordinate storage pools in the storage hierarchy. The copies remain in the disk storage pool, but in a cached state, so that subsequent retrieval requests are satisfied quickly. However, if space is needed to store new data in the disk storage pool, cached files are erased, and the space reused for the new data.

The reason to use a cache for a disk storage pool is that caching shortens some file retrieval times for the server. When you use a cache, a copy of the file remains on fast disk storage after the server migrates the primary file to another storage pool. You might want to consider using a disk storage pool with caching enabled to store space-managed files that clients frequently access. Using a cache can result in the following conditions

• Increase the time for client backup operations to complete.

• Require more space for the Tivoli Storage Manager database.

6) You can use the MIGRATE STGPOOL command to run migration manually for a random access or sequential access primary storage pool.

migrate storagepool diskpool lo=0

The MIGRATE STGPOOL command also uses the following extra parameters

• DUration: Specifies the maximum number of minutes the migration runs before being automatically canceled. You can specify a value from 1 to 9999. If not specified, the server stops only after the low migration threshold is reached.

• LOwmig: For random-access and sequential-access disk storage pools, specifies that the server stops migration when the amount of data in the pool is at or below this percentage of the pool’s estimated capacity. This parameter is optional. You can specify a number from 0 to 99. The default value is the LOWMIG attribute of the storage pool definition.

• REClaim: Specifies whether to attempt reclamation for the storage pool before performing the migration. You can specify this parameter only for a sequential-access storage pool. This parameter is optional. The default is No.

         No: Specifies that the server does not attempt a reclamation before starting the                      migration.

         Yes: Specifies that the server attempts reclamation before starting the migration.

• Wait: Specifies whether to wait for the server to complete processing this command in the foreground. This parameter is optional. The default is No.

         No: Specifies that the server processes this command in the background.

         Yes: Specifies that the server processes this command in the foreground.

Read More

[facebook src="Uptodatewithme" width="500" height="400" hide-cover="true" posts="true"/]