>From the TSM 5.1 Admin Guide: Defining and Updating FILE Device Classes
The FILE device type is used for storing data on disk in simulated storage volumes. The storage volumes are actually files. Data is written sequentially into standard files in the file system of the server machine. You can define this device class by issuing a DEFINE DEVCLASS command with the DEVTYPE=FILE parameter. Because each volume in a FILE device class is actually a file, a volume name must be a fully qualified file name. Note: Do not use raw partitions with a device class type of FILE. When you define or update the FILE device class, you can specify the parameters described in the following sections. Mount Limit The mount limit value for FILE device classes is used to restrict the number of mount points (volumes or files) that can be concurrently opened for access by server storage and retrieval operations. Any attempts to access more volumes than indicated by the mount limit causes the requester to wait. The default value is 1. The maximum value for this parameter is 256. Note: The MOUNTLIMIT=DRIVES parameter is not valid for the FILE device class. When selecting a mount limit for this device class, consider how many TSM processes you want to run at the same time. TSM automatically cancels some processes to run other, higher priority processes. If the server is using all available mount points in a device class to complete higher priority processes, lower priority processes must wait until a mount point becomes available. For example, TSM cancels the process for a client backup if the mount point being used is needed for a server migration or reclamation process. TSM cancels a reclamation process if the mount point being used is needed for a client restore operation. For additional information, see "Preemption of Client or Server Operations" on page 357. If processes are often cancelled by other processes, consider whether you can make more mount points available for TSM use. Otherwise, review your scheduling of operations to reduce the contention for resources. Maximum Capacity Value You can specify a maximum capacity value that restricts the size of volumes (that is, files) associated with a FILE device class. Use the MAXCAPACITY parameter of the DEFINE DEVCLASS command. When the server detects that a volume has reached a size equal to the maximum capacity, it treats the volume as full and stores any new data on a different volume. The default MAXCAPACITY value for a FILE device class is 4MB. Directory You can specify the directory location of the files used in the FILE device class. The default is the current working directory of the server at the time the command is issued, unless the DSMSERV_DIR environment variable is set. For more information on setting the environment variable, refer to Quick Start. 146 Tivoli Storage Manager for Sun Solaris: Administrator's Guide The directory name identifies the location where the server places the files that represent storage volumes for this device class. While processing the command, the server expands the specified directory name into its fully qualified form, starting from the root directory. Later, if the server needs to allocate a scratch volume, it creates a new file in this directory. The following lists the file name extension created by the server for scratch volumes depending on the type of data that is stored. For scratch volumes used to store this data: The file extension is: Client data .BFS Export .EXP Database backup .DBB Database dump and unload .DMP Michael French Savvis Communications IDS01 Santa Clara, CA (408)450-7812 -- desk (408)239-9913 -- mobile -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Helen Tam Sent: Tuesday, January 06, 2004 9:21 AM To: [EMAIL PROTECTED] Subject: Re: Unload/LoadDB question Hello, Pardon my ignorance, what is a file-based device class? Thanks, Helen At 09:14 AM 1/6/2004 -0600, you wrote: >Our experience has been that deleting old dbvols does not clean up the >db like an unloaddb/loaddb does. > >By all means, run the unload/load to a file-based device class. A tape >dump will take *way* too long. > >-- >Mark Stapleton ([EMAIL PROTECTED]) > > >-----Original Message----- >From: French, Michael [mailto:[EMAIL PROTECTED] >Sent: Mon 1/5/2004 22:33 >To: [EMAIL PROTECTED] >Cc: >Subject: Re: Unload/LoadDB question >This was actually the first thing I tried. The DB was originally 177GB >and 20% utilized. I reduced the DB by 50GB and then deleted volumes >and mirrors. I tried to shrink it again by another 35-40GB's, but it >complained saying that it could not be reduced by that much, that there >was not enough free table space. I think the offline unloaddb/loaddb >is the only way to fix this: > >tsm: TSM2.USSNTC6>q db > >Available Assigned Maximum Maximum Page Total Used > Pct Max. > Space Capacity Extension Reduction Size Usable Pages > Util Pct > (MB) (MB) (MB) (MB) (bytes) Pages > Util >--------- -------- --------- --------- ------- --------- >--------- >----- ----- > 136,260 119,928 16,332 16,332 4,096 30,701,56 11,396,64 > 37.1 38.0 > 8 2 > > >-----Original Message----- >From: ADSM: Dist Stor Manager on behalf of David Longo >Sent: Mon 1/5/2004 8:02 PM >To: [EMAIL PROTECTED] >Cc: >Subject: Re: Unload/LoadDB question >Another way to do it is live. If your utilization is that low AND you >have the DB spread over many volumes, say 10GB in size. > >Then do a "reduce DB 10000", takes generally less than a minute. Then >delete one of the dbvols that is that size. (delete it's mirrors >first). Any data on the volume is copied to the other dbvols and then >the one requested is deleted from TSM DB. (This step can take an hour >or two or so depending on system load, etc. "q pro" shows progress. > >You can repeat as needed. As I said, this can be done live without the >downtime required for DB unload/load and reduces the size of your DB. > > > >David B. Longo >System Administrator >Health First, Inc. >3300 Fiske Blvd. >Rockledge, FL 32955-4305 >PH 321.434.5536 >Pager 321.634.8230 >Fax: 321.434.5509 >[EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 01/05/04 08:17PM >>> >System Info: > >Solaris 8 >Sun E4500 w/ 4 processors & 4GB RAM >TSM 5.1.8.1 >TSM DB 119GB (37.1% utilized) > > I tried shrinking the DB down to 85GB and at 100GB, ran into the > "your outta SQL table space" message. Guess it's time for an > unloaddb/loaddb. Any ideas at all how long I can expect this to take, > even an educated guess would be a good place to start. Also, can I > dump the DB to a disk class I define to speed up the process (raw > volume preferably, I will do a DB backup before starting this)? > Thanks. > >Michael French >Savvis Communications >IDS01 Santa Clara, CA >(408)450-7812 -- desk >(408)239-9913 -- mobile > > >############################################################## >This message is for the named person's use only. It may contain >confidential, proprietary, or legally privileged information. No >confidentiality or privilege is waived or lost by any mistransmission. >If you receive this message in error, please immediately delete it and >all copies of it from your system, destroy any hard copies of it, and >notify the sender. You must not, directly or indirectly, use, >disclose, distribute, print, or copy any part of this message >if you are not the intended recipient. Health First reserves >the right to monitor all e-mail communications through its >networks. Any views or opinions expressed in this message >are solely those of the individual sender, except (1) where >the message states such views or opinions are on behalf of >a particular entity; and (2) the sender is authorized by >the entity to give such views or opinions. >##############################################################
