Scratch Tapes Needed

Flyboy60

ADSM.ORG Member
Joined
Jul 1, 2017
Messages
13
Reaction score
0
Points
0
PREDATAR Control23

I am a TSM newbie - TSM admin left and everything defaulted to me.
Scratch tapes are my issue.
I have ordered new tapes from our vendor, but that will take 2 weeks , time I do not have.
My onsite storage pool (tapes) is basically full. My Offsite storage pool has many tapes that are full but with low percentage usage.
My question is this, can I checkin (if offsite) tapes from the offsite storage pool, migrate the data and then use the tapes as scratch to tie me over til the new tapes arrive?
If this is possible, what is the process and pitfalls if any?

q stg

Storage Device Estimated Pct Pct High Low Next Storage Pool Name Pool Pool Name Class Name Capacity Util Migr Mig Mig
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- ----------
DISK_DD DD 23,873 G 94.0 94.0 90 70 ONSITE

OFFSITE TS3200DEV- 873,978 G 3.0
CL
ONSITE TS3200DEV- 837,542 G 2.3 3.4 90 70
CL
 
PREDATAR Control23

What you will need to do is reclaim tapes. Hopefully you have enough room on filling tapes in your ONSITE pool to do some reclaimation and free some tapes so you can do reclaim some of your OFFSITE pool.

Start first with "reclaim stg onsite th=60". See if that is able to reclaim anything.

The real win for you should be reclaiming your OFFSITE pool. The thing is though you will need one scratch tape to start this. If you have one free scratch tape run "reclaim stg offsite th=60 offsitereclaiml=5". This will start start reclaiming up to 5 tapes with less than 40% full. Good initially to limit the number of tapes it tries to reclaim at one time.

This is assuming that DRM is setup correctly at your site.

It would be useful to see the results of "q vol stg=onsite" and "q vol stg=offsite". I wouldn't try just checking in offsite tapes. Let reclaimation free up the partially used tapes.
 
PREDATAR Control23

I have blank LTO5 tapes with no labels - I have been waiting on labels now for a week.
In my onsite pool, all tapes are over 90% utilized and in my offsite pool there are numerous tapes with 0.0% utilization.
If only I can checkin those blank tapes that have no labels (barcode), that would help.
I will post the results of the onsite and offsite storage pools once I get back in office.
 
PREDATAR Control23

What is your reuse period? Do a 'q stgpool <storage_pool_name_of_offsite_pool> f=d' - look for 'Delay Period for Volume Reuse:' If this is a high number, say 8, try reducing this value to a lower number and see it some offsite tapes go to Vault Retrieve mode. You can go all the way to ZERO and see the effect. REMEMBER: this is supposed to be temporary. Return to the original value once you get back tapes as this is a DR setting which is another story.

If this does not do the trick, you need to run a reclamation of the offsite storage pool, and see if tapes go to Vault Retrieve. NOTE: this may fail since your online tape pool is almost 100% utilized.
 
PREDATAR Control23

>q v stg=onsite

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
B00105L5 ONSITE TS3200DEV- 1.6 T 100.0 Full
CL
B00113L5 ONSITE TS3200DEV- 1.6 T 60.6 Full
CL
B00131L5 ONSITE TS3200DEV- 1.6 T 46.5 Full
CL
B00135L5 ONSITE TS3200DEV- 1.5 T 55.2 Full
CL
B00146L5 ONSITE TS3200DEV- 1.6 T 95.8 Full
CL
B00153L5 ONSITE TS3200DEV- 1.6 T 61.8 Full
CL
B00154L5 ONSITE TS3200DEV- 1.6 T 82.6 Full
CL
B00156L5 ONSITE TS3200DEV- 1.5 T 72.4 Full
CL
B00158L5 ONSITE TS3200DEV- 1.6 T 52.8 Full
CL
B00162L5 ONSITE TS3200DEV- 1.7 T 35.9 Full
CL
B00171L5 ONSITE TS3200DEV- 1.5 T 96.4 Full
CL
B00176L5 ONSITE TS3200DEV- 1.5 T 39.7 Full
CL
B00190L5 ONSITE TS3200DEV- 1.6 T 93.0 Full
CL
B00208L5 ONSITE TS3200DEV- 1.6 T 51.8 Full
CL
D00009L5 ONSITE TS3200DEV- 2.7 T 51.0 Filling
CL
D00010L5 ONSITE TS3200DEV- 1.6 T 97.3 Full
CL
D00011L5 ONSITE TS3200DEV- 1.5 T 91.5 Full

>q v stg=offsite

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
B00101L5 OFFSITE TS3200DEV- 1.5 T 0.0 Full
CL
B00103L5 OFFSITE TS3200DEV- 1.5 T 62.6 Full
CL
B00104L5 OFFSITE TS3200DEV- 1.6 T 0.4 Full
CL
B00106L5 OFFSITE TS3200DEV- 2.7 T 52.9 Filling
CL
B00108L5 OFFSITE TS3200DEV- 1.6 T 0.0 Full
CL
B00109L5 OFFSITE TS3200DEV- 1.6 T 0.1 Full
CL

>q stg offsite f=d

Storage Pool Name: OFFSITE
Storage Pool Type: Copy
Device Class Name: TS3200DEVCL
Estimated Capacity: 873,978 G
Space Trigger Util:
Pct Util: 3.0
Pct Migr:
Pct Logical: 97.9
High Mig Pct:
Low Mig Pct:
Migration Delay:
Migration Continue:
Migration Processes:
Reclamation Processes: 1
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold:
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 100
Offsite Reclamation Limit: No Limit
Maximum Scratch Volumes Allowed: 500
Number of Scratch Volumes Used: 72
Delay Period for Volume Reuse: 0 Day(s)
Migration in Progress?:
Amount Migrated (MB):
Elapsed Migration Time (seconds):
Reclamation in Progress?: No
Last Update by (administrator): ADMIN
Last Update Date/Time: 02/22/11 11:34:01
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?:
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:
Deduplicate Data?: No
Processes For Identifying Duplicates:
Duplicate Data Not Stored:
Auto-copy Mode:
Contains Data Deduplicated by Client?: No

Here is the info requested.
 
PREDATAR Control23

You could try printing some temporary labels yourself - https://tapelabel.de/

Is that your complete list of offsite tapes? There is far more data in your onsite pool than your offsite pool if that is the complete list.

Anyway, as moon-buddy said - offsite reclaimation. You do not have enough space in filling tapes to reclaim anything with your onsite pool.
 
PREDATAR Control23

No - not my complete offsite . Its just too long to put in the post.

ANR1163W Offsite volume B00142L5 still contains files which could not be moved.
ANR1163W Offsite volume B00193L5 still contains files which could not be moved.
ANR1163W Offsite volume B00116L5 still contains files which could not be moved.
ANR1163W Offsite volume B00149L5 still contains files which could not be moved.
ANR1163W Offsite volume B00150L5 still contains files which could not be moved.
ANR1163W Offsite volume B00209L5 still contains files which could not be moved.
ANR1163W Offsite volume B00202L5 still contains files which could not be moved.
ANR1163W Offsite volume B00200L5 still contains files which could not be moved.
ANR1163W Offsite volume B00152L5 still contains files which could not be moved.
ANR0985I Process 3491 for SPACE RECLAMATION running in the FOREGROUND completed with completion state
FAILURE at 21:04:23.
ANR1893E Process 3491 for SPACE RECLAMATION completed with a completion state of FAILURE.
ANR4936I The reclamation of the OFFSITE storage pool is complete. Number of files reclaimed: 0. Number
of reclaimed bytes: 0. Number of reclaimed deduplicated bytes: 0. Number of reconstructed files: 0.
Number of unreadable files: 0.
ANS8001I Return code 4.


Volume Name: B00142L5
Storage Pool Name: OFFSITE
Device Class Name: TS3200DEVCL
Estimated Capacity: 1.5 T
Scaled Capacity Applied:
Pct Util: 0.8
Volume Status: Full
Access: Offsite
Pct. Reclaimable Space: 99.3
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 7
Write Pass Number: 1
Approx. Date Last Written: 05/13/17 18:29:01
Approx. Date Last Read: 05/10/17 08:04:06
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location: VAULT
Volume is MVS Lanfree Capable : No
Last Update by (administrator): ADMIN
Last Update Date/Time: 06/22/17 11:45:55
Begin Reclaim Period:
End Reclaim Period:
Drive Encryption Key Manager: None
Logical Block Protected: No

Volume Name: B00193L5
Storage Pool Name: OFFSITE
Device Class Name: TS3200DEVCL
Estimated Capacity: 1.6 T
Scaled Capacity Applied:
Pct Util: 0.7
Volume Status: Full
Access: Offsite
Pct. Reclaimable Space: 99.4
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 1
Write Pass Number: 1
Approx. Date Last Written: 05/15/17 23:32:13
Approx. Date Last Read: 05/15/17 12:46:12
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location: VAULT
Volume is MVS Lanfree Capable : No
Last Update by (administrator): ADMIN
Last Update Date/Time: 06/22/17 11:46:10
Begin Reclaim Period:
End Reclaim Period:
Drive Encryption Key Manager: None
Logical Block Protected: No


Volume Name: B00116L5
Storage Pool Name: OFFSITE
Device Class Name: TS3200DEVCL
Estimated Capacity: 1.4 T
Scaled Capacity Applied:
Pct Util: 0.6
Volume Status: Full
Access: Offsite
Pct. Reclaimable Space: 99.6
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 1
Write Pass Number: 1
Approx. Date Last Written: 05/16/17 09:51:11
Approx. Date Last Read: 05/15/17 23:32:13
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location: VAULT
Volume is MVS Lanfree Capable : No
Last Update by (administrator): ADMIN
Last Update Date/Time: 06/22/17 11:46:25
Begin Reclaim Period:
End Reclaim Period:
Drive Encryption Key Manager: None
Logical Block Protected: No
 
PREDATAR Control23

Ok, these tapes aren't the problem. It is the tapes which hold the original data. Reclaimation is likely to have failed because it was unable to load tapes which have the primary data. Try "q vol access=unavail". Then you need to work out why TSM can't load these tapes.
 
PREDATAR Control23

>q vol access=unavail

Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
B00102L5 EOD_SP TS3200DEV- 1.3 T 37.1 Full
CL
B00121L5 EOD_SP TS3200DEV- 2.7 T 38.7 Filling
CL
B00191L5 EOD_SP TS3200DEV- 1.4 T 1.9 Full
CL


Volume Name: B00102L5
Storage Pool Name: EOD_SP
Device Class Name: TS3200DEVCL
Estimated Capacity: 1.3 T
Scaled Capacity Applied:
Pct Util: 37.1
Volume Status: Full
Access: Unavailable
Pct. Reclaimable Space: 62.9
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 73
Write Pass Number: 1
Approx. Date Last Written: 09/06/16 04:50:31
Approx. Date Last Read: 07/14/16 17:54:26
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location:
Volume is MVS Lanfree Capable : No
Last Update by (administrator):
Last Update Date/Time: 05/21/16 06:19:46
Begin Reclaim Period:
End Reclaim Period:
Drive Encryption Key Manager: None
Logical Block Protected: No

q libv

Library Name Volume Name Status Owner Last Use Home Device
Element Type
------------ ----------- ---------------- ---------- --------- ------- ------
DC_TS3200 B00102L5 Private 4,098 LTO
DC_TS3200 B00105L5 Private 4,130 LTO
DC_TS3200 B00109L5 Private Data 4,119 LTO
DC_TS3200 B00113L5 Private Data 4,122 LTO
DC_TS3200 B00119L5 Private Data 4,124 LTO
DC_TS3200 B00121L5 Private Data 4,135 LTO
DC_TS3200 B00124L5 Private Data 4,134 LTO
DC_TS3200 B00130L5 Private Data 4,109 LTO
DC_TS3200 B00131L5 Private Data 4,121 LTO
DC_TS3200 B00132L5 Private Data 4,115 LTO
DC_TS3200 B00135L5 Private Data 4,100 LTO
DC_TS3200 B00139L5 Private Data 4,113 LTO
DC_TS3200 B00146L5 Private Data 4,106 LTO
DC_TS3200 B00151L5 Private Data 4,133 LTO
DC_TS3200 B00152L5 Private 4,102 LTO
DC_TS3200 B00153L5 Private Data 4,111 LTO
DC_TS3200 B00154L5 Private Data 4,118 LTO
DC_TS3200 B00155L5 Private 4,132 LTO
DC_TS3200 B00156L5 Private Data 4,120 LTO
DC_TS3200 B00157L5 Private Data 4,105 LTO
DC_TS3200 B00158L5 Private Data 4,101 LTO
DC_TS3200 B00159L5 Private Data 4,116 LTO
DC_TS3200 B00162L5 Private Data 4,099 LTO
DC_TS3200 B00165L5 Private Data 4,131 LTO
DC_TS3200 B00167L5 Private Data 4,117 LTO
DC_TS3200 B00168L5 Private Data 4,114 LTO
DC_TS3200 B00170L5 Private Data 4,129 LTO
DC_TS3200 B00171L5 Private Data 4,097 LTO
DC_TS3200 B00176L5 Private 4,107 LTO
DC_TS3200 B00190L5 Private Data 4,123 LTO
DC_TS3200 B00199L5 Private Data 4,112 LTO
DC_TS3200 B00203L5 Private Data 4,110 LTO
DC_TS3200 B00204L5 Private Data 4,108 LTO
DC_TS3200 B00207L5 Private 4,126 LTO
DC_TS3200 D00009L5 Private Data 4,127 LTO
DC_TS3200 D00010L5 Private Data 4,128 LTO
DC_TS3200 D00011L5 Private Data 4,125 LTO
DC_TS3200 D00043L5 Private 4,103 LTO
DC_TS3200 D00074L5 Private 4,104 LTO
 
PREDATAR Control23

Ok, the first two unavailable tapes are in the library. Try "upd vol B00102L5 access=readw" and "upd vol B00121L5 access=readw" and then re-run reclaimation. Look for errors in the activity log if these tapes go unavailable again.

Tape B00191L5 is not in the library. Best to find that tape.
 
PREDATAR Control23

Just thought I'd put this out here. Depending on how much disk space you have in your TSM server you could try setting up a reclamation storage pool and then reclaim your primary storage pool.
https://www.ibm.com/support/knowled...com.ibm.itsm.srv.doc/t_reclaim_one_drive.html
I've had to do this in the past, its clunky due to the steps involved but it works. Just make sure you have enough landing space to hold at least two tape volumes worth of data (taking into account you look to be using LTO5 media with drive compression). Also, you'll need to make sure you have tape resources (drives and scratch tapes) to move the data back from the reclamation pool to the tape pool. I see that you have a few volumes with very low utilization. If you could, I'd focus on those first.

This won't help if your source volumes are unavailable however.
 
PREDATAR Control23

Update
I was able to find tape 191 and checked it in as private and updated its access to read write. I ran a reclamation on the offsite stgpool with a threshold of 60, it took forever but no vault retrieves were created. I noticed that the primary stgpool (disk pool) gained about 900g of space.
Below is the scrip that controls our maintenance jobs

Name Line Command
Number
---------- ------ ------------------------------------------------------------
SCRIPT- 1 PARALLEL


2 backup stgpool DISK_DD OFFSITE maxprocess=1
SHREDTONOSHRED=NO wait=yes
3 backup stgpool ONSITE OFFSITE wait=yes
4 SERIAL
5 backup db devclass=TS3200DEVCL type=FULL wait=yes
6 PREPARE SOURCE=DBBACKUP WAIT=YES
7 BACKUP VOLHIST FILE=VOLHIST.DR
8 BACKUP DEVCONFIG FILE=DEVCONFIG.DR
9 migrate stgpool DISK_DD lowmig=80 wait=yes
10 reclaim stgpool ONSITE threshold=80 wait=yes
11 reclaim stgpool OFFSITE threshold=80 wait=yes
12 expire inventory skipdirs=no wait=yes resource=4
13 RECLAIM STG DISK_DD THRESHOLD=20 DURATION=480


RecoveryOne - I don't have the disk space for what you are suggesting. Backups are about 1.2T per night.

I found a tape in the library that was empty, so I did a q content and q vol on it to verify.
As soon as I checked it in as scratch, the migration process from disk to tape started filling it up, giving me no chance to perform a reclamation on the Offsite stgpool.
I am starting to think that the only way out of this dilema is with 3 tapes - 2 for migration and the other for reclamation.

I am thinking that aftr the disk_dd reclamation is complete, depending on space gain, I will move data from a full onsite tape 30+% utilized to disk_dd and use that for the Offsite reclamation.

Thanks for all the help.
 
PREDATAR Control23

Ok. The long and short of it is that you just need more scratch tapes. Did any tapes go back to unavailable? Are you keeping all the primary tapes in the library?

To get by until you have your tape labels, here are the steps I would take once you have a free scratch tape..

Limit the number of offsite tapes you try to reclaim at a time. If you have 40 tapes within threshold, it will try to reclaim them all at once and it will take forever. Perhaps start out with limiting it to 5. With the number of barely used tapes, it won't take long. You can set this limit with "upd stg offsite offsitereclaiml=5"

Change the reclaimation thresholds in your script for the onsite and offsite pool to 60. Reclaiming at 80 will leave many tapes with between 20-40% full. If you are short on tapes, this is wasteful. You may need to limit the duration of the reclaimation to ensure it completes before you need the tape drives for something else.

Have you had a look at printing your own labels? https://tapelabel.de/

When I first started with TSM, our operators complained that they were always having to add new scratch tapes and something was wrong. I audited the tapes we were holding offsite and I found we had 120 scratch tapes at the offsite location that TSM knew nothing about. With a bit of digging, I found we were emailing a list of tapes to retrieve 7 days a week to the operators but they were only retrieve the tapes Mon-Fri and the Sat, Sun emails were being ignored. Change of process and the problem was sorted. An audit of your offsite tapes may find tapes which have been forgotten.
 
PREDATAR Control23

No worries, was trying to think outside the box in a supported way :)
And yes, need more tapes....

My immediate concern is of your database.
Your script has this line:
5 backup db devclass=TS3200DEVCL type=FULL wait=yes
So, your database full backups are going to tape and is going to use scratch tapes. As you have no scratch tapes, its likely failing. How many previous database backups are you keeping?
You could do a
Code:
q volhist type=dbb
to see your oldest BACKUPFULL media. Please post here the list if you can.

I was thinking, you might be able to get a few scratch tapes from those old database backup tapes. Do you have any scripts running a del volhist type=dbb? However, I recommend you do not manually run a del volhist type=dbb just yet. Lets see what volumes you are using for old database backups first.

That said, you may want to look at 'q db f=d' and look for the line 'Last Complete Backup Date/Time' as well. Then a 'q log f=d'. How much space do you have free in Archive Log Directory? I'm concerned if you don't have scratch tapes for reclamation, you don't have any tapes for your database backup. If your database doesn't backup, Archive Log becomes full and your TSM server comes down. It will be much harder to recover if TSM halts vs trying to reclaim a storage pool. At that point, a PMR would likely be needed to IBM. Two weeks without any database backups is asking for failure IMO.

Have you had a look at printing your own labels? https://tapelabel.de/
DazRaz, that's very handy. I'll have to keep it tucked away!
If you can, what DazRaz has stated could tide you over till your real labels come on site.

In addition to what DazRaz said in their post, you may want to temporally comment out the migration line of your daily maintenance script if you can - and if you DISK_DD pool has space for a night or two of backups, till you successfully reclaim a volume from your primary tape pool. Depending on when your script is running, it could as you stated above, immediately take the tape you just made available and use it for its own.

To recap as I started to write this and got distracted a few times...
At this point, let us know what the results of:
  • q volhist type=dbb
  • q db f=d (look for Last Complete backup Date/Time)
  • q log f=d Look for the Free Space on File System something like below:
    Code:
              Archive Log Directory: /tsminst1/tsmarclog
    Total Space of File System (MB): 783,360.00
    Used Space on File System (MB): 343,257.45
    Free Space on File System (MB): 440,102.55
  • Do you have any tape volumes in a pending state for your primary tape pool? As moon-buddy posted above, but this time do a q stg <primary tape pool name> and look for 'Delay Period for Volume Reuse'
Next steps:
  • If you have a lot (greater than 10 days) of database backup volumes and no recent db backup I suggest, at your own risk, of removing an old database backup, and first running a new full backup till completion. This will clear out your Active Log and keep the system running that much longer.
    • May not be a bad idea to do a 'q proc' and cancel the migration process if you see it waiting for a mount point before doing any thing such as removing old database backups. Which I'll imagine is the case till it times out. If you don't the migration process will come in and take your tape.
  • If you have a lot (greater than 10 days) and a recent backup volume (of within 24 hours or so and log space) I suggest, at your own risk, of removing an old database backup, and then trying to use that tape as your reclaim tape for your primary storage pool.
    • Again, look at q proc and cancel the migration process if you see it waiting for mount.

Over all sounds like your resources are pretty lean so you may have to make sacrifices of daily backups from clients till your TSM server gets healthier.

I just want to make it clear that I feel the people on the forums here are some of the best in the world when it comes to TSM, and if any of them contradict what I've posted above, or calls it just plain wrong take their advice over mine! Just trying to look at the problem from a different view point.
 
PREDATAR Control23

Here is the info requested:


>q volhist type=dbb

Date/Time: 02/07/15 09:31:09
Volume Type: BACKUPFULL
Backup Series: 671
Backup Operation: 0
Volume Seq: 10,001
Device Class: FILECLASS
Volume Name: /tsmarchlog/tsm/23319468.DBV
Volume Location:
Command:
Database Backup ID High: 0
Database Backup ID LOW: 0
Database Backup Home Position: 0
Database Backup HLA:
Database Backup LLA:
Database Backup Total Data Bytes (MB) : 0
Database Backup total Log Bytes (MB) : 0
Database Backup Block Num High: 0
Database Backup Block Num Low: 0
Database Backup Stream Id: 1
Database Backup Volume Sequence for Stream: 10,001

Date/Time: 02/07/15 19:22:40
Volume Type: BACKUPFULL
Backup Series: 672
Backup Operation: 0
Volume Seq: 10,001
Device Class: FILECLASS
Volume Name: /tsmarchlog/tsm/23354960.DBV
Volume Location:
Command:
Database Backup ID High: 0
Database Backup ID LOW: 0
Database Backup Home Position: 0
Database Backup HLA:
Database Backup LLA:
Database Backup Total Data Bytes (MB) : 0
Database Backup total Log Bytes (MB) : 0
Database Backup Block Num High: 0
Database Backup Block Num Low: 0
Database Backup Stream Id: 1
Database Backup Volume Sequence for Stream: 10,001

Date/Time: 02/09/15 10:13:12
Volume Type: BACKUPFULL
Backup Series: 673
Backup Operation: 0
Volume Seq: 10,001
Device Class: FILECLASS
Volume Name: /tsmarchlog/tsm/23494791.DBV
Volume Location:
Command:
more... (<ENTER> to continue, 'C' to cancel)

Database Backup ID High: 0
Database Backup ID LOW: 0
Database Backup Home Position: 0
Database Backup HLA:
Database Backup LLA:
Database Backup Total Data Bytes (MB) : 0
Database Backup total Log Bytes (MB) : 0
Database Backup Block Num High: 0
Database Backup Block Num Low: 0
Database Backup Stream Id: 1
Database Backup Volume Sequence for Stream: 10,001

Date/Time: 02/09/15 13:29:05
Volume Type: BACKUPFULL
Backup Series: 674
Backup Operation: 0
Volume Seq: 10,001
Device Class: FILECLASS
Volume Name: /tsmarchlog/tsm/23506545.DBV
Volume Location:
Command:
Database Backup ID High: 0
Database Backup ID LOW: 0
Database Backup Home Position: 0
Database Backup HLA:
Database Backup LLA:
Database Backup Total Data Bytes (MB) : 0
Database Backup total Log Bytes (MB) : 0
Database Backup Block Num High: 0
Database Backup Block Num Low: 0
Database Backup Stream Id: 1
Database Backup Volume Sequence for Stream: 10,001

Date/Time: 06/20/17 07:12:01
Volume Type: BACKUPFULL
Backup Series: 729
Backup Operation: 0
Volume Seq: 100,001
Device Class: TS3200DEVCL
Volume Name: D00074L5
Volume Location: VAULT
Command:
Database Backup ID High: 0
Database Backup ID LOW: 0
Database Backup Home Position: 0
Database Backup HLA:
Database Backup LLA:
Database Backup Total Data Bytes (MB) : 0
Database Backup total Log Bytes (MB) : 0
Database Backup Block Num High: 0
Database Backup Block Num Low: 0
Database Backup Stream Id: 1
more... (<ENTER> to continue, 'C' to cancel)

Database Backup Volume Sequence for Stream: 100,001

>q db f=d

Database Name: TSMDB1
Total Size of File System (MB): 409,600
Space Used on File System(MB): 138,170
Space Used by Database(MB): 138,075
Free Space Available (MB): 271,430
Total Pages: 13,408,868
Usable Pages: 13,405,220
Used Pages: 13,330,092
Free Pages: 75,032
Buffer Pool Hit Ratio: 99.9
Total Buffer Requests: 274,869,525,487
Sort Overflows: 0
Package Cache Hit Ratio: 99.4
Last Database Reorganization: 07/11/17 05:42:05
Full Device Class Name: TS3200DEVCL
Number of Database Backup Streams: 1
Incrementals Since Last Full: 0
Last Complete Backup Date/Time: 06/19/17 15:57:20
Compress Database Backups: No


>q log f=d

Active Log Directory: /actlog
Total Space(MB): 102,400
Used Space(MB): 683
Free Space(MB): 101,717
Archive Log Directory: /archlog
Total Size of File System (MB): 921,600.00
Space Used on File System (MB): 286,867.74
Free Space(MB): 634,732.26
Archive Log Compressed: No
Mirror Log Directory:
Total Size of File System (MB):
Space Used on File System (MB):
Free Space(MB):
Archive Failover Log Directory:
Total Size of File System (MB):
Space Used on File System (MB):
Free Space(MB):

>q stg onsite f=d
Session established with server : AIX
Server Version 7, Release 1, Level 1.100
Server date/time: 07/12/17 03:33:08 Last access: 07/12/17 01:47:09


Storage Pool Name: ONSITE
Storage Pool Type: Primary
Device Class Name: TS3200DEVCL
Estimated Capacity: 831,210 G
Space Trigger Util:
Pct Util: 2.5
Pct Migr: 3.8
Pct Logical: 99.3
High Mig Pct: 90
Low Mig Pct: 70
Migration Delay: 0
Migration Continue: Yes
Migration Processes: 1
Reclamation Processes: 1
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 100
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 500
Number of Scratch Volumes Used: 19
Delay Period for Volume Reuse: 0 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
Last Update by (administrator): ADMIN
Last Update Date/Time: 02/09/15 09:30:49
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?: Yes
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:
Deduplicate Data?: No
Processes For Identifying Duplicates:
Duplicate Data Not Stored:
Auto-copy Mode: Client
Contains Data Deduplicated by Client?: No
 
PREDATAR Control23

Well, there goes my hope of you having multiple database backup's to tape, and that we could reuse some. Seems you only have one from this year on tape. Also, no luck with volumes waiting in limbo with the reuse delay period on your primary tape pool.

You currently have plenty of Archive Log free space, HOWEVER not doing a database backup daily may render all of your data backed up from 06/19/17 15:57:20 to current date useless if the server were to crash and a restore of the database was needed.

At this point FlyBoy60 I am out of "good, or even risky idea's". See if you can get those labels for your tapes asap, or really look into trying to print your own LTO labels from the link DazRaz posted as a workaround until the real labels arrive.
 
PREDATAR Control23

I owe a HUGE thank you to everyone that responded to my emergency plea for help.
You guys ROCK!!!
The labels came just as I was on the brink of running out of disk space with no scratch tapes.
It was a good experience (not to be repeated) I learned a ton.
All is good now - followed everything you guy suggested.

Thank you.
 
PREDATAR Control23

Welcome, sorry couldn't be more of assistance.
Do make sure you are backing up your database daily! And determine how long you need to keep those database backup volumes.

Best wishes.
 
Top