Issue 1:
After upgrading the Tivoli Storage Manager server from Version 6.1 or V6.2 to V6.3, it might not be possible to restore the V6.1 or V6.2 database.
After upgrading the Tivoli Storage Manager server from Version 6.1 or V6.2 to V6.3, it might not be possible to restore the V6.1 or V6.2 database.
Solution
After an upgrade of Tivoli Storage Manager to V6.3, all volume history records are changed to the new format. If the user wants to revert the system to the previous version by reinstalling the Tivoli Storage Manager V6.1 or V6.2 software and restoring the V6.1 or V6.2 database, the database restore fails. The reason is that the required volume history information is lost.
To avoid this issue, save a copy of the V6.1 or V6.2 volume history file before upgrading to V6.3. Use the saved volume history file when restoring the V6.1 or V6.2 database. Upgrade Tivoli Storage Manager to 6.3.3 which will contain APAR IC83120-when available.
Also Read: Installation & Configuration of IBM Spectrum Protect (TSM) Server
To avoid this issue, save a copy of the V6.1 or V6.2 volume history file before upgrading to V6.3. Use the saved volume history file when restoring the V6.1 or V6.2 database. Upgrade Tivoli Storage Manager to 6.3.3 which will contain APAR IC83120-when available.
Also Read: Installation & Configuration of IBM Spectrum Protect (TSM) Server
Deduplicated data that is imported into a non-deduplicated storage pool might be incorrectly stored on the target system. Under certain rare conditions, the data might become inaccessible on the target system. The data on the source system will not be affected and will be accessible.
RECOMMENDATION:
Before issuing an IMPORT NODE command to copy deduplicated data to a non-deduplicated target storage pool, apply the Tivoli Storage Manager server fixing level 6.2.4.000 or higher, which contains the fix for APAR IC80755.
If you previously issued the IMPORT NODE command, prior to applying the fixing level, the following operations can be performed to determine if any of the imported data has been affected:
- If the imported data has been backed up to a copy storage pool, run the validate extents utility as shown below:
VALIDATE EXTENTS <primary storage pool> <copy storage pool> action=fixextents
- If the imported data has not been backed up to a copy storage pool, the data in the storage pool can be moved/copied with any of the following server operations to detect data that has been incorrectly stored:
BACKUP STGPOOL
MIGRATE STGPOOL
MOVE DATA
MOVE NODEDATA
All of the operations above will flag any data found to be incorrectly stored as damaged. The damaged data can then be deleted and either re-imported from source server or backed up from originating client machine.
PROBLEM RESOLUTION:
When the 6.2.4.000 or higher fixing level is applied, the Tivoli Storage Manager server will properly store all data during the import process.
Solution:
Do not import deduplicated data to a non-deduplicated storage pool until you have installed fixing level 6.2.4.000 or higher.
Also Read: Difference between Server-side and Client-side Deduplication
Issue 3:
Analyzing very large files in a deduplicated storage pool on Tivoli Storage Manager Version 6.1 and 6.2 may cause the active log to run out of space or cause other sessions or server processes to stall.
Analyzing very large files in a deduplicated storage pool on Tivoli Storage Manager Version 6.1 and 6.2 may cause the active log to run out of space or cause other sessions or server processes to stall.
Recommendation:
Use the following circumventions or upgrade to Tivoli Storage Manager 6.3.
Solution:
- If the storage pool with deduplication enabled has a NEXTSTGPOOL defined, customers can use the MAXSIZE parameter to prevent very large files from being stored in the deduplicated storage pool. Bypassing the deduplicated storage pool prevents large files from being analyzed and causing the problems described in this flash. A recommended value for MAXSIZE is 50G.
- If an Identify Duplicates process begins processing a very large file, issue the QUERY PROCESS command and find the process. Note the volume that the process is currently analyzing. Cancel all Identify Duplicates processes and update the volume to make its status UNAVAILABLE. This will prevent future Identify Duplicates process from selecting the volume. If the volume is needed for a client restore or retrieve, cancel any Identify Duplicates processes running at the time and update the volume status to READONLY. Once the client restore/retrieve has completed, update the volume status to UNAVAILABLE again and resume the Identify Duplicates processes as needed. Once the fix has been applied, update the status of any volumes that were made UNAVAILABLE to READONLY . The Identify Duplicates processes will then begin processing any files on the volumes that have not already been analyzed.
Issue 4:
The serviceability aid tsmdiag may delete valuable data without warning when using the -results parameter.
Content
The tsmdiag utility deletes all files and directories in the results directory specified on the command line when using the -results parameter.
If you inadvertently specify a directory containing valuable information, e.g. /etc or /usr, the whole directory (including subdirectories) will be deleted.
The fixed version will require that the specified -results directory be empty to ensure that no data is deleted.
Recommendation:
- Always ensure the -results directory you specify does NOT contain any valuable data.
- Upgrade to a level of Tivoli Storage Manager containing the fix for IC62818
0 Comment to "Problems and solutions for common TSM DB and Deduplication issues"
Post a Comment