Re: q act says *No match found*
Is the TSM db full? Do a q DB.. if the DB fills up I believe no more activity log entries can be entered in the DB. Also keep in mind a simple "q act" only shows activity for the past hour. It's possible nothing happened in the past hour.. try "q act begind=today-1" for the past 24 hours. -Gerald -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Chetan H. Ravnikar Sent: Saturday, September 21, 2002 10:24 AM To: [EMAIL PROTECTED] Subject: q act says *No match found* Any help is appreciated, I am wondering how can this happen, a fully functional server now does not give any activity log please help thanks tsm: server1>q act ANR2034E QUERY ACTLOG: No match found using this criteria. ANS8001I Return code 11. tsm: server1>
Re: q act says *No match found*
I have seen this problem before. When I saw it, it was because we had tape drives getting a lot of fibre channel SCSI errors and causing all kinds of locking apparently. You may want to check to make sure something like that is not happening. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Chetan H. Ravnikar [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 21, 2002 3:06 PM To: [EMAIL PROTECTED] Subject: Re: q act says *No match found* Ok I bounced the server and things look OK, :) On Sat, 21 Sep 2002, Bob Booth - UIUC wrote: > Date: Sat, 21 Sep 2002 13:04:05 -0500 > From: Bob Booth - UIUC <[EMAIL PROTECTED]> > Reply-To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: q act says *No match found* > > Hard to tell whats going on. Is this a fresh install of TSM? What > version? What platform is it? > > Do a 'q stat' and check to see what your activity log retention period > is.. It is possible to set the ACTLOGRETENTION to 0, thereby turning > it off. > > hope this helps, > > bob > > On Sat, Sep 21, 2002 at 10:23:34AM -0700, Chetan H. Ravnikar wrote: > > Any help is appreciated, > > I am wondering how can this happen, a fully functional server now > > does not give any activity log > > > > please help > > > > thanks > > > > > > tsm: server1>q act > > ANR2034E QUERY ACTLOG: No match found using this criteria. ANS8001I > > Return code 11. > > > > tsm: server1>
Re: RAW volumes or not
There have been recommendations to never use VxFS for TSM Database and Storage Volumes posted on this list that I never quite understood. However, I am suspecting that the issue has to do with setting up VxFS correctly, similar to the file system maxperm issues on AIX. I am not sure how JFS and VxFS were compared here. It would have had to been different hardware which throws a wrinkle in the results. Until just a few months ago VxFS was not available for AIX. More often than not, it is the way the file systems are setup and the hardware they are on versus one or the other so long as they have the similar features of JFS and VxFS. This is based on my testing of XFS on IRIX, JFS on AIX, and VxFS on Solaris all on the same disk subsystem, an IBM ESS all fibre channel connected. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Bob Booth - UIUC [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 21, 2002 3:34 PM To: [EMAIL PROTECTED] Subject: Re: RAW volumes or not I have used both on AIX, and really have never seen a difference either way. I use LVM raw volumes for both, since I find them easier to deal with. TSM mirrors the database/log volumes, and AIX mirrors the storage pool volumes. TSM V5 can utilize AIO for JFS under with AIX, and this is a different ball- game altogether. I am not actually sure if JFS is native on Solaris, you have to have Veritas installed, and this will render a significant improvment over the native Solaris filesystem I/O. Check with your sources to see if they are indeed running Veritas on their Sun systems. I have compared VXFS and AIX JFS on machines of the same performance characteristics, and they perform about the same (under various tests VXFS did beat JFS, I used IOZONE). Seeing arguments either way, I use raw LV's for ease of configuation and smaller overhead (no jfslog, etc). good luck. bob On Sat, Sep 21, 2002 at 07:03:38PM -, Arni Snorri Eggertsson wrote: > Hiya, > > I've been reading about using RAW volumes for database and diskpool > volumes, my impression is that when running AIX and using JFS the > benefits are trivial. However I've seen people talking about 200-300% > performance increase when running TSM on Solaris. > > What I am wondering is if anyone has actually done experiments with > this on AIX on a real environment, i.e. performance check using JFS on > one hand and then RAW volumes on the other? > > > > thanks, > Arni Snorri Eggertsson > [EMAIL PROTECTED]
Re: RAW volumes or not
I have used both on AIX, and really have never seen a difference either way. I use LVM raw volumes for both, since I find them easier to deal with. TSM mirrors the database/log volumes, and AIX mirrors the storage pool volumes. TSM V5 can utilize AIO for JFS under with AIX, and this is a different ball- game altogether. I am not actually sure if JFS is native on Solaris, you have to have Veritas installed, and this will render a significant improvment over the native Solaris filesystem I/O. Check with your sources to see if they are indeed running Veritas on their Sun systems. I have compared VXFS and AIX JFS on machines of the same performance characteristics, and they perform about the same (under various tests VXFS did beat JFS, I used IOZONE). Seeing arguments either way, I use raw LV's for ease of configuation and smaller overhead (no jfslog, etc). good luck. bob On Sat, Sep 21, 2002 at 07:03:38PM -, Arni Snorri Eggertsson wrote: > Hiya, > > I've been reading about using RAW volumes for database and diskpool volumes, my >impression is that when running AIX and using JFS the benefits are trivial. However >I've seen people talking about 200-300% performance increase when running TSM on >Solaris. > > What I am wondering is if anyone has actually done experiments with this on AIX on a >real environment, i.e. performance check using JFS on one hand and then RAW volumes >on the other? > > > > thanks, > Arni Snorri Eggertsson > [EMAIL PROTECTED]
Re: q act says *No match found*
Ok I bounced the server and things look OK, :) On Sat, 21 Sep 2002, Bob Booth - UIUC wrote: > Date: Sat, 21 Sep 2002 13:04:05 -0500 > From: Bob Booth - UIUC <[EMAIL PROTECTED]> > Reply-To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: q act says *No match found* > > Hard to tell whats going on. Is this a fresh install of TSM? What version? > What platform is it? > > Do a 'q stat' and check to see what your activity log retention period is.. > It is possible to set the ACTLOGRETENTION to 0, thereby turning it off. > > hope this helps, > > bob > > On Sat, Sep 21, 2002 at 10:23:34AM -0700, Chetan H. Ravnikar wrote: > > Any help is appreciated, > > I am wondering how can this happen, a fully functional server now does not > > give any activity log > > > > please help > > > > thanks > > > > > > tsm: server1>q act > > ANR2034E QUERY ACTLOG: No match found using this criteria. > > ANS8001I Return code 11. > > > > tsm: server1>
RAW volumes or not
Hiya, I've been reading about using RAW volumes for database and diskpool volumes, my impression is that when running AIX and using JFS the benefits are trivial. However I've seen people talking about 200-300% performance increase when running TSM on Solaris. What I am wondering is if anyone has actually done experiments with this on AIX on a real environment, i.e. performance check using JFS on one hand and then RAW volumes on the other? thanks, Arni Snorri Eggertsson [EMAIL PROTECTED]
Re: q act says *No match found*
Bob thanks for the response. I am running TSM 4.2.20 and this is not a new install.. a production server which has been working for a few months. is this to do with space issues.. q stat says Accounting: On Activity Log Retention Period: 14 Day(s) Activity Summary Retention Period: 60 Day(s) On Sat, 21 Sep 2002, Bob Booth - UIUC wrote: > Hard to tell whats going on. Is this a fresh install of TSM? What version? > What platform is it? > > Do a 'q stat' and check to see what your activity log retention period is.. > It is possible to set the ACTLOGRETENTION to 0, thereby turning it off. > > hope this helps, > > bob > > On Sat, Sep 21, 2002 at 10:23:34AM -0700, Chetan H. Ravnikar wrote: > > Any help is appreciated, > > I am wondering how can this happen, a fully functional server now does not > > give any activity log > > > > please help > > > > thanks > > > > > > tsm: server1>q act > > ANR2034E QUERY ACTLOG: No match found using this criteria. > > ANS8001I Return code 11. > >
Re: q act says *No match found*
Hard to tell whats going on. Is this a fresh install of TSM? What version? What platform is it? Do a 'q stat' and check to see what your activity log retention period is.. It is possible to set the ACTLOGRETENTION to 0, thereby turning it off. hope this helps, bob On Sat, Sep 21, 2002 at 10:23:34AM -0700, Chetan H. Ravnikar wrote: > Any help is appreciated, > I am wondering how can this happen, a fully functional server now does not > give any activity log > > please help > > thanks > > > tsm: server1>q act > ANR2034E QUERY ACTLOG: No match found using this criteria. > ANS8001I Return code 11. > > tsm: server1>
q act says *No match found*
Any help is appreciated, I am wondering how can this happen, a fully functional server now does not give any activity log please help thanks tsm: server1>q act ANR2034E QUERY ACTLOG: No match found using this criteria. ANS8001I Return code 11. tsm: server1>
Re: DB Volume "Reorg" using Delete DBVOLUME
I have tried this, and I observed the same thing as Wayne. DELETE DBVOLUME will not force any reorganization. It runs too fast to be attempting any beneficial reorganization. It just moves whole pages, without regard to what parts of the B-tree shrubbery are in them. But also I have not seen it make fragmentation worse either. (Fragmentation is something I'm studying; it's more complicated an issue than I first realized, but more about that at some other time.) Once your DB gets to a certain size, it is no longer reasonable to perform an UNLOAD/LOAD operation, because it would require more downtime that we can afford. (i.e. something approximating the time it takes milk to go bad in a properly adjusted refrigerator) So we just have to accept a certain steady state of fragmentation as the working reality. (There is a rumor of something in the pipeline by developers that might help this - comments from anyone that went to SHARE in San Francisco?) (Thank goodness those minor database bumbs and bruises are pretty well self-healed by continuous migration, expiration, and reclamation!) But, what you CAN achieve via DELETE DBVOLUME, and this is the ONLY way, is I/O load balancing between physical volumes. Monitor this with Q DBVOL F=D. If you lay out your new DBVOLs so that they will all be pretty full, when you delete the old ones, the database will be balanced among the new ones. Then, how do you grow? Allocate new DBVOLS on the SAME physical vols as the ones you just spread your database out among, but make sure the new ones are physically adjacent to the existing ones. This works best with JBOD disks; those Gigantic Black Boxes 'O Raid are too unimaginably complex to contemplate load balancing. Stage 1 Stage 2Stage 3 10gb DB 6gb DB 10gb DB 55% full 92% full 55% full unbalanced balanced balanced PV1 PV2PV3 PV4 PV3 PV4 +-+-+ +-+-+ |5gb | | | 2gb | 2gb | |100% | | |empty|empty| |full | |+-+-+ +-+-+ | | || 3gb | 3gb | | 3gb | 3gb | | |5gb ||not |not | |not |not | | |10% ||quite|quite| |quite|quite| | |full ||full |full | |full |full | +-+-++-+-+ +-+-+ Why do PV1 and PV2 change to PV3 and PV4? If they are not separate, the DELETE DBVOL that takes place between Stage 1 and Stage 2 will take forever, making your disk arms thrash so hard the drives could walk across the floor. Another strategy I have (inadvertently!) used is to "fatten up" the database by disabling expiration for a while, move/balance it with DELETE DBVOL, and then trim it back down by restarting expiration. This second strategy, though, will certainly increase fragmentation. Nobody in their right mind would do this deliberately, but I did do it and it worked extremely well for load balancing. (i.e. I'm at Stage 2, balanced, and now only 60% full.) Just remember that this is not an exact science, but with load balancing precision is not necessary. Approximate will do. DANGER! BEWARE! If you are using TSM Mirroring, your database will NOT be mirrored during the DELETE DBVOL operation. Make a full DB backup before you start, and contemplate OS or hardware mirroring or RAID as a temporary measure while it is underway. TIVOLI: It would sure be nice to DELETE DBVOL all mirror copies at once, in a mirrored fashion! Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] "In theory, theory and practice are the same, = = but in practice, theory and practice are different." = On Fri, 20 Sep 2002, Wayne T. Smith wrote: >That would be a nice feature, but, at least on my Tivoli ADSM V3 server, > doing a couple of volumes (about 5 gig out of 15 in use) had no effect >on reported % utilization whatsoever.cheers, wayne > >Seay, Paul wrote, in part: >> One of our TSM Support Staff members went to the advanced class and was led >> to believe you could get some reorg benefits doing the following >> >> Define New DB Volumes whereever you want them. >> Perform DELETE DBVOLUME commands on each of the existing DBVOLUMEs >> one at a time which causes the data to be moved. >> >> Our DBVOLUMES are on ESS disk so they are not mirrored. Thus, the delete >> causes a move of all the current data to other volumes. >> >> Has anyone ever heard of doing this to get some reorganization benefits? >> If so, were the benefits, mild or significant? >> >> I would not be surprised if massive filespace deletes could be recaptured by >> doing this. >
Re: (Silly?) DB2 Backup question
Hi Bill, Yes you will be able to restore the database from online backup but before online db restore you must restore db logs that have been active during online backup into log_dir directory and after restore you must rollforward db to end of logs .for successful restore you need only logs than have been active during online backup if you want point in time recovery than you need all logs that you have taken after backup Main difference between online backup restore and offline backup restore is that you dont need logs during offline restore.DB2 specialist recommendet at least one offline backup per week. Bill Boyer cc: Sent by: "ADSM: Subject: Re: (Silly?) DB2 Backup question Dist Stor Manager" <[EMAIL PROTECTED] T.EDU> 20.09.2002 21:18 Please respond to "ADSM: Dist Stor Manager" There is a redbook, Backing up DB2 Using TSM SG24-6247 that has sample scripts for different full/log backup retention using the DB2ADUTL utility. I have this running using only ONLINE backups plus the DB2 user exit supplied by TSM for transaction log archiving. My biggest question has been if I only take ONLINE backups with the LOGS will I be able to restore the database, or do I need to do occassional OFFLINE backups to be able to recover? I also believe that the ONLINE backup does backup the log records that have occurred during the backup.I remember reading something about this somewhere, but I can't find it again. So I won't say I'm 100% sure about this. I do know that after an ONLINE backup the DB2ADUTL shows me with additional LOG backups, too. Bill Boyer DSS, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Levinson, Donald A. Sent: Friday, September 20, 2002 1:40 PM To: [EMAIL PROTECTED] Subject: Re: (Silly?) DB2 Backup question Log files are absolutely required if you are performing online backups. A. the database has to be in logretain mode to allow an online backup B. all transactions that occur during an online backup only go to log and won't be captured in the backup AFAIK. Otherwise logfile archiving is only necessary if you are interested in recovering the data that was committed after the last backup, if it is acceptable to lose all the data that is entered between backups then there is no need to archive log files. The practice I use is to perform offline backups every night (my outage window allows this) and log archives whenever a log is released, the log archives have a 30 day retention. Or you could hack together a script to backup the released logs and then delete them after the next successful offline DB2 backup so that TSM marks them as deleted. -Original Message- From: Lars Bebensee [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:18 AM To: [EMAIL PROTECTED] Subject: (Silly?) DB2 Backup question Hi guys and girls, this question is one of the general sort, so forgive me if it has been answered here or in some manual I haven't red yet. Probably, I just need a simpler description. AFAIK, there are three ways to backup a database: 1. Offline filesystem backup 2. Offline backup in the databases quiesced mode via some api 3. Online backup via api The first question I have is about the transaction log archiving. With which of the above does it make sense and why? The second one: does it make sense to run offline AND online backups in a backup cylce, or will one of them be save enough? I read through the TSM Redbook on DB2 UDB implementation. It just explains the ways RDBMS backups can be done not which combinations are useful. As far as I could extract, it is rather useless doing offline backups and log file archiving but no online backups, right?? Thanks in advance Lars This transmittal may contain confidential information intended solely for the addressee. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (collect at 907-564-1000) and ask to speak with the message sender. In addition, please immediately delete this message and all attachments. Thank you.
