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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Steven Harris
Sent: Sunday, September 09, 2012 8:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
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.