>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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Helen Tam
Sent: Tuesday, January 06, 2004 9:21 AM
To: ADSM-L AT VM.MARIST DOT EDU
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 (stapleton AT berbee DOT com)
>
>
>-----Original Message-----
>From: French, Michael [mailto:Michael.French AT SAVVIS DOT NET]
>Sent: Mon 1/5/2004 22:33
>To: ADSM-L AT VM.MARIST DOT EDU
>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: ADSM-L AT VM.MARIST DOT EDU
>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
>david.longo AT health-first DOT org
>
>
> >>> Michael.French AT SAVVIS DOT NET 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.
>##############################################################
|
