Hi Steve, Windows CAN be made to work the same way, and in my experience that's the best thing do to: make many drive letters and treat each drive letter like you would an AIX filesystem, with one (or more) drive letters for the DB, one for the active log, one for the archive log. Just like on AIX, all you have to do is create a directory on the drive letter. DB2 creates all the subdirectories, files, etc on his own.
DB2 on Windows, like on AIX, does his %full calculations based on the amount of space on the drives where the DB and logs are located, just like it would do the %full calculations based on the amount of space in an AIX filesystem. If you let other stuff live on the same drive letter, you'll end up getting DB backups fired when you shouldn't because the drive space is being used by something else, or you'll have to leave way too much free space on that drive to prevent it happening. It's not impossible to manage all on one big drive, but it's ugly - Nothing Good Will Come of It. DB2 expects to have separate filesystems/drives, and your life will be better if you do it that way. If you have good connections to SAN based storage like XIV or a VNX, you can format and connect multiple LUNs as different drive letters. Set up your fastest drive(s) for the DB (which wants fast random access), the active log (which wants fast sequential access), and the archive log (which can be on slower disk). If you are stuck with a less flexible or dedicated array, think about making at least some of it RAID 10 for the DB, still presenting multiple LUNs to the Windows TSM server. If what you end up stuck with is one big physical LUN, use Windows Device Manager to carve it into multiple logical LUNS, so it will appear as different drive letters. W -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Steven Harris Sent: Sunday, September 09, 2012 8:30 PM To: [email protected] Subject: [ADSM-L] Disk/Volume/mountpoint access for TSM 6.3 on Windows Hi All The TSM Documentation is, compared to much I have seen, wonderful. It covers system functions and facilities marvellously, but what it doesn't do well is spell out best practices from the numerous options available. I am installing TSM 6.3 on windows. Long term readers will recall my travails with NDMP and linux. The solution is to locate the widows client on this new server box and back up using a proxy node thta resides on the server. On Linux, AIX the layout is simple, one volume for DB another for active log, a third for archive log. Windows does not in general work this way. Looking at the DB2 doc for windows it seems that the DB is allocated as a number of files of a given size, but the examples place the archive log in its own windows drive letter, without explicitly stating why. Does anyone have experience of how to layout the TSM 6 database on Windows that they would be willing to share? RTFM is a valid response if you tell me which manual to read. I've already tried the obvious without finding what I'm looking for, but may have overlooked some clue. Thanks Steve Steven Harris TSM Admin Canberra Australia.
