Oh vastly experienced TSM wise ones! We have a box with some large files, and a slow network, so I turned on compression to see if it would speed the backup, but I think it may have backfired. It looks to me like I just caused resends.
>From the client schedule.log: 10/02/2001 04:45:27 Normal File--> 109,740,032 /fnsw/local/oracle/oraIDB_sig Compressed Data Grew 10/02/2001 04:45:47 Retry # 1 Normal File--> 109,740,032 /fnsw/local/oracle/oraIDB_sig Sent >From the UNIX Using the Backup-Archive Clients manual: The compression option compresses files before you send them to the server. Compressing your files reduces data storage for backup versions and archive copies of your files. It can, however, affect TSM throughput. A fast processor on a slow network connection benefits from compression, but a slow processor on a fast network connection does not. If you specify compressalways=yes, compression continues even if the file size increases. To stop compression if the file size grows, and resend the file uncompressed, specify compressalways=No. </quote> Am I really reading that right, that the client sent the data twice? I was hoping that it would compress it client side, then if it looked good it would send the compressed version, otherwise it would send the uncompressed version. But it looks like it sends most of the compressed version, and then the uncompressed version. How annoying. If that is the case then I need to go through and count up how many (and how large) files grew during compression and compare with the count and size of the files that didn't and decide if I should use compression allways, or turn compression back off. But before I go to that much work I wanted to confirm that I am reading the situation correctly. Thanks for your input! Kai.
