We need to perform scheduled full/cold backups of a 1TB Oracle database on a Sun Enterprise 10000 (E10K) server running Solaris 8 and TSM Server/Client v5.1. The server has a local 30-slot tape library with 4 SCSI DLT7000 drives, and a 32GB diskpool. TSM Shared Memory protocol and both "SELFTUNE..." settings are enabled. The Oracle database is comprised of very large files (most are 10GB) across 20 filesystem mountpoints (RAID 1+0).
We defined 1 TSM Client node with ResourceUtilization=10, collocation disabled, compression disabled and the DevClass Format=DLT35C (DLT7000, hardware compression enabled). The Backup CopyGroup is directed to a Primary TapePool. The DiskPool is 30GB, but is not used for the Oracle DB backup because of the huge filesizes. GOOD - During the first backup we saw 4 active data sessions and 4 mounted tapes at all times. The backup used all 4 drives 100% of the time, and because of hardware compression ultimately used only 4 tapes. NOT SO GOOD - The backup took approx 18.5 hours, which translates to about 13.5 GB/hour per tape drive. We expected to achieve 25GB/hour per drive (based on prior performance with TSM 3.7 on the same hardware). BAD - portions of every filespace (possibly even portions of each 10GB file?) were scattered across all 4 tapes BAD - a subsequent 'BACKUP STGPOOL <tapepool> <copypool>' had to decompress then recompress all 1TB of data, & took longer than the backup BAD - a subsequent Disaster Recovery test took 30 hours - we couldn't find any 'dsmc' command-line syntax to initiate a multi-threaded restore for multiple filespaces. We had to initiate filespace restores individually and sequentially to avoid tape contention problems (i.e., strong likelihood of concurrent threads or processes requesting data from different locations on the same 4 tapes at the same time) We cannot backup to DiskPool and let Migration manage tape drive utilization, because the individual files are so large (10GB) that they would almost immediately flood the 30GB DiskPool. Q1 - We are considering whether to set TSM Client Compression=Yes and use DevClass Format=DLT35 (instead of DLT35C) to solve the decompress/recompress problem. However, there will then be 4 TSM Client processes performing cpu-intensive data compression plus the TSM Server process, all running concurrently on one server. Will that be too processor-intensive, & could the server deliver data fast enough to keep all 4 drives streaming? Q2 - We are also considering whether to set Collocation=Filespace to permit multiple concurrent restores with minimal tape contention. Wouldn't that use 20 or more tapes during a backup instead of just 4, and wouldn't we overrun our library's 30-slot limit just doing the 1st backup, 1st 'BACKUP STGPOOL <tapepool> <copypool>' and 1st 'Backup DB' ? Q3 - How can we boost performance of the tape drives back to 25GB/hour? What are likely reasons why TSM 5.1 is only getting 13.5GB/hour? Q4 - If we set Collocation=Filespace, can we limit the number of tapes used, or influence TSM's selection of tapes, during backup? Q5 - Does backup of 10GB files to a local tape device via Shared Memory require special performance tuning? What else should we do - increase slots/drives; increase DiskPool size; return to the 4-logical-node model and abandon multi-threading in both backups and restores; other? Comments & recommendations welcome - rsvp, thanks Kent Monthei GlaxoSmithKline
