Re: Antwort: Re: MOVE DATA - Reconstruct Yes/No
Probably the default is NO to make the current behaviour of MOVE DATA consistent with older versions, where the reconstruct option did not exists and where MOVE DATA did not reconstruct aggregates. Today, I allways use RECONST=YES. Gerhard Wolkerstorfer [EMAIL PROTECTED] schrieb: I hardly can see any differences in the performance. [EMAIL PROTECTED] (Karel Bos) am 29.07.2002 12:08:26 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: (Blindkopie: Gerhard Wolkerstorfer/DEBIS/EDVG/AT) Thema:Re: MOVE DATA - Reconstruct Yes/No Performance?? -Oorspronkelijk bericht- Van: Gerhard Wolkerstorfer [mailto:[EMAIL PROTECTED]] Verzonden: maandag 29 juli 2002 7:38 Aan: [EMAIL PROTECTED] Onderwerp: MOVE DATA - Reconstruct Yes/No Hi all, is there any reason, why a MOVE DATA command with Reconstruct=No should be used ? The default is NO. I always use YESand cannot see any bad things.. Regards Gerhard Wolkerstorfer -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: TSM DB design (was Re: TSM 5.1 Performance Tuning Guide - Where?)
Besides the more academic question, whether a B-tree plus SQL interface is a relational DB, the more interesting point for me is the fact, that this SQL interface is incomplete. It e.g. does not tell me, on which volume a specific backup copy of a file is lying. (It tells me all the volumes that contain a backup copy of that file; but which volume contains the active copy?) I assume, that the SHOW command would give me that information (I did not try it), so the SHOW command is native interface to that DB. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: LTO don't need clean up?
Mark Stapleton [EMAIL PROTECTED] schrieb: From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Tomá¹ Hrouda one of LTO 3583 (2 drives) we take care of still didn't clean drives. It is operate from january 2002 and there is about 10-20 GB daily data flow through each drive, 3-5 daily tape-mounts. Both drives are set to ASNEEDED cleaning frequency, but no clean occured from january (!!), no dirty drive signalized on display ... is it possible? LTO box is placed in climatized dust-free environment, but .??? Has anyone some similar experience with LTO clean frequency? IBM LTO libraries clean themselves; you shouldn't be using TSM to schedule cleanings. Set your tape drives to CLEANFREQ=NONE and RTM at http://www-1.ibm.com/support/manager.wss?rt=4org=ssgdoc=570001038aid=1 This URL yields an empty document. You probably meant it to be http://www-1.ibm.com/support/manager.wss?rt=4org=ssgdoc=S7000103aid=1 Anyway, on page 86 this document states: Whenever a drive requires cleaning, it alerts you with a message on the library operator panel or host console. ... Host cleaning Host/Application maintained and activated is the default condition. Host cleaning enables the server to detect the need to clean an Ultrium Tape Drive and to control the cleaning process. The cleaning cartridge must be stored in one of the available storage slots within the library. For more information, see the section about cleaning in your application software documentation. Manual cleaning Manual cleaning requires that you use the Move Media command from the library s operator panel to insert a cleaning cartridge into the library to perform cleaning on one or more of the Ultrium Tape Drives (see Move Media Dialog on page 106). To me this means, that you - either watch the library's operator panel, and response to a drive's need to be cleaned by inserting a cleaning cartrige and using the Move Media Dialog, - or let the application software, i.e. TSM, control the cleaning. I strongly prefer the second method. And I'm sharing Tomá¹ Hrouda's concerns: Our 3583, which is in production since Feb. 2001 and currently receives about 60 GB data per night, has never cleaned a drive, at least according to the Cleanings Left number yielded by QUERY LIBVOL. I just started a cleaning cycle by hand (CLEAN DRIVE), just to verify that this changes the Cleanings Left number. It does. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Mirrored DELETE DBVOL, LOGVOL?
Roger, I agree, I also feel very uncomfortable living without a mirror, even for a limited time. The admin interface should be enhanced to allow for distinguishing between removing a DBCOPY from deleting the entire DBVOL including all mirrors (and hence moving the contents while all mirrors are in place). In the past, I have always added the new volume as a mirror first, then deleted an old copy, then added a new mirror, ... Since this procedure does not allow changing the volume size, the volumes on my nearly 8 years old server are now much too small. The necessary consolidation exposes me to the danger described by you, so I'm hesitating ... Roger Deschner [EMAIL PROTECTED] schrieb: Oh, I guess it's just my paranoid mind at work again, but DELETE DBVOL scares me. I'm using it to migrate the TSM Database from old disks to new, faster disks. So, I attached the new dbvol and its mirror, fiddled with EXTEND DB and REDUCE DB to make it right, and did DELETE DBVOL on the old mirror. Then I did DELETE DBVOL on the old primary copy. Oops! Now I'm really exposed! There is only one copy of the old database volume, while this rather lengthly copying process proceeds. Is there any way to do a DELETE DBVOL in a mirrored way - that is delete all mirrored copies of a DBVOL at once, so that if a disk crashes in the middle of it, I will not lose my Database? That's the whole point of Database mirroring, isn't it? I'm starting to think AIX JFS mirroring might have some advantages over TSM Database/Log mirroring. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Consolidating TSM servers.
There is no way (AFAIK), to export/import the database information only, without exporting/importing the data. This is a major deficiency of TSM, which not only occurs when consolidating TSM servers, but also when consolidating TSM clients: When transfering a huge filespace from one client to another, you essentially run into the same problem, even if the TSM server remains the same. The ability to export/import the database information for - the whole TSM server - a specific client - a specific filespace of a specific node without exporting/importing the data itself, would help. Reinhard Daniel Sparrman [EMAIL PROTECTED] schrieb: Hi The problem isn't moving only one TSM server, but consolidating two TSM servers into one. I have no problems moving the first TSM server(ADSM1) to the new hardware. However, I want to migrate the second TSM server(ADSM2) to the new hardware/TSM server(TSM1). There are two choices for doing this, either exporting all nodes using export node option. This will generate alot of tapes, as the smallest ADSM server has 200 nodes, 1500 tapes and a total storage of 30TB. However, I can choose not to export the copypools, which would make it about 15TB of data and 750 tapes. The other option is to do a export server. This command has a filedata= feature, and what I would like to do is to do a export server filedata=none, and then import this information into the new TSM server. The new TSM server will have access through ACSLS/3494 CU to all existing volumes from both old ADSM servers. Therefore, I wouldn't have to export all the filedata, only definitions. My question is, is it possible to do a export server filedata=none, and then import this information into the new server, connect both the 3494 and the STK9310 to the new server, and use the old volumes that contains data and already exists in the 3494/STK9310. This would save me 3-4 days, because that is what it would take to move 15TB of data from the 3494 to the 9310 using import/export commands. Or, do I have to do export/import of all filedata, because doing filedata=none, will only import node definitions, and not storage volume definitions? Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 Don France (TSMnews) [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 2002-04-23 08:45 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Consolidating TSM servers. If you stay on the same platform-OS, all you need to do is shutdown (old server) after a final DB backup, move the HW connections to the new server, restore DB, and you're finished. Remember to copy the dsmserv.dsk (filesystems for all TSM server files -- db, log, disk pool vols, logical volumes, path-names), as well as volhist, devcfg and dsmserv.opt; move/re-org filesystems *after* the move. Many other posts confirm this approach, have personally done it on AIX since v2 days. Regards, Don France Technical Architect - Tivoli Certified Consultant Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] - Original Message - From: Daniel Sparrman To: [EMAIL PROTECTED] Sent: Monday, April 22, 2002 12:59 PM Subject: Consolidating TSM servers. Hi Anybody out there know if it's possible to do a export server, without having to export all filedata, and then do a import and use the existing tapes. We have one STK 9310 and one IBM 3494. Each TSM server has a copypool and a primary tape pool in the different libraries. All equipment is SAN connected, so if I could first do a DB backup/restore to the new machine of one of the TSM servers, and then export everything except for the file data from the second TSM server to the new machine, it would be perfect. Doing a export server filedata=all, would create about 1500 new tapes, according to a export server preview=yes (about 31TB of data) and this would probbaly not work at all. So, anybody done this before? Best Regards Daniel Sparrman --- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 HÄGERNÄS Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Update TSM
I did something very similar two weeks ago: from TSM 4.1.2 upgrade to 4.2.1 and further to 4.2.1.15. Two remarks: - After installing 4.2.1 from CD, the DRM license certificate (drm.lic) was missing. I fetched it from an older 4.2.0 installation. - The fileset tivoli.tsm.devices.aix43.rte is still on level 4.2.1.0. A newer level of this fileset is contained in fix 4.2.1.13, but not in 4.2.1.15. So, if you want to have it, you will have to upgrade to 4.2.1.13 in between. You might also consider upgrading to 4.2.2.0, which I did on a different server on Tuesday (from 4.1.2 via 4.2.1.0 to 4.2.2.0). Besides the drm.lic issue, it went smoothly. Istiak Mahmud [EMAIL PROTECTED] schrieb: I am working on upgrading tSM 4.1.1.0 to 4.2.1.15. I've aix 4.3.3.0 platform. As I understand that I've to upgrade(migrate) to 4.2.1.0 level first and install upto 4.2.1.15 level. I'd like to know if you have any procedure or experience that can help me to accomplish this job. Thankyou. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Unwanted, unscheduled FULL Backups
Does full backup mean that all files are backed up? I have seen this on several occasions: - due to the DST error in some client versions (see APAR IC28544), - when the client's admin changed the ACLs on all files on the client, - when a filespace was renamed on the client, - ... I do not think, that this is a TSM database problem. Jon Adams [EMAIL PROTECTED] schrieb: Here's an interesting one for us: periodically, a client will decide to perform a full backup during a scheduled incremental, regardless of existing file spaces or status of the client files or options in any way, shape or form. Does anyone know of any setting or issue that would cause this to happen? It has happened about three times on three different clients in the last several months and the best we can come up with is a possible TSM database corruption. Any idea's would be greatly appreciated, as always. We're running TSM v4.1x on AIX v5.x with all flavors of Windows and AIX clients. _ Regards, Jon R. Adams IT IPS BST Infrastructure Premera Blue Cross 425-670-5770 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Checkin after teach library
Hello, I'm not sure about the result of audit library in that situation, and specifying meaningful volranges for scratch and private volumes may be difficult (al least at our site it would)... What I did in a similar situation: Before upgrading, I produced a library inventory (mtlib -l /dev/lmcp0 -qI from AIX), wrote the output (which containes the volume name, category and some further information) into a file, edited each line in that file to become mtlib -l /dev/lmcp0 -C -Vvolser -tcategory (replace volser by the volume name, and category by the original category), and executed that script after the upgrade. brian welsh [EMAIL PROTECTED] schrieb: Hello, Library 3494, drives 3590B, AIX 4.3.3, TSM 4.1.1.0 Next weekend our shared library (with a few lpar's/S-390) will be extended. IBM says, that by setting the library online, and after the 'TEACH' all the tapes probably return to an INSERT-category. This means we have to check in all our tapes (600). We are intending to do the following: - audit library - checkin libvol libname status=scratch search=yes volr=...,... checkl=no devt=3590 - checkin libvol libname status=private search=yes volr=...,... checkl=no devt=3590 I have three questions: 1. Is this the right way? 2. Is every tape mounted during the checkin? 3. Has anyone done this before and how long did it take? Thanks, Brian _ Meld je aan bij de grootste e-mailservice wereldwijd met MSN Hotmail: http://www.hotmail.com/nl -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: How to remove space management from TSM Client
The natural way to achieve this, would be a dsmmigfs remove, but this process recalls all files ... So maybe you try something like the following (which I did not test): - unmount the filesystems - kill the HSM processes (and prevent them from being started again -- rc.adsmhsm in inittab) - delete or reuse the filesystem (to reuse it, you might have to remove adsmfsm = true from the according entries in /etc/filesystems) To delete the migrated files from the TSM server you would command delete filespace node_name file_space_name type=spacemanaged Kilchenmann Timo [EMAIL PROTECTED] schrieb: Hello, Can someone please give me some advice about this: On the current NSM we are using a space managment pool. We would like to reuse the tapes from this pool for backup purposes and to stop using HSM. The reason: NSM is running out of scratch tapes for backup; HSM is not needed any more. We now use HSM only on one server (AIX 4.2.0) on two filesystems. HSM does not work properly and we do not want to use it anymore. Also these filesystems with HSM are not needed anymore BUT their backup should be kept (in the backup storage pool). I.e. we may completely delete these filesystems from the server disk. We cannot recall the data from the spmg pool as there is no space on filesystem. Recall is also not needed as this data has been restored from backup to another location. (But we still want to KEEP the original backup.) Could someone please indicate the right procedure to achieve this target. Thank you and kind regards, Miljenka -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Encryption experience?
Hi, does anybody use the encryption features of the TSM client? Any experience (good or bad)? A peculiar problem I have is that I cannot make it work for non-root users (AIX and Linux client). With the settings suggested in the TSM for Unix manual (i.e. PASSWORDACCESS GENERATE and ENCRYPTKEY SAVE), a non-root user is not able to restore a file which was encrypted during backup (by root). The message: ANS1101E User not authorized to decrypt /home/mersch/encrypt/ttt. And if a non-root user backups or archives a file, which is matched by include.encrypt, it is NOT encrypted. This leads me to the impression, that encryption is not available for non-root users, which is in contrast to the documentation. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Data Retention
Gerald Wichmann [EMAIL PROTECTED] schrieb: So there is no reason to ever set retain only to less then retain extra right? hmm - perhaps to prevent this MC to apply to directory backups (when DIRMC is not specified) ??? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
ANR0102E dsalloc.c(952): Error 1 inserting row ...
Hello, last night my server (4.1.2.0 on AIX 4.3.3) showed a lot of errors: ANR0102E dsalloc.c(952): Error 1 inserting row in table DS.Segments. They were accompanied by some dying client sessions: ANR0530W Transaction failed for session 83419 for node X (AIX) - internal server error detected. Anybody seen this? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: selective backup?
Eugene Awyong - Singapore [EMAIL PROTECTED] schrieb: I use the selective backup function to do a daily backup of 2 directories in one of my servers. It is run via crontab, this is how the script file looks like dsmc selective /documentum/ /oracle7/ However, I realise when I do it, it doesn't quite seem to back up the directories below that of these 2 directories? Try dsmc selective -subdir=yes /documentum/ /oracle7/ or include the following line into your dsm.opt, to make it the default: SUBDIR YES -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: TSM and 3590E Tapes
Louis Wiesemann [EMAIL PROTECTED] schrieb: Thanks. One thing I'm not clear on is whether I need to set the old B tapes to readonly or can I let TSM do it for me. IBM says that the new drives will not write over a non-scratch tape in the old format. When TSM calls for an output tape and the drive detects the old format will it genrate an error that causes TSM to mark the tape readonly and then mount a scratch tape? Or should I set the B tapes to readonly before bringing TSM up with the new drives? If I remember correctly, the TSM-Sever internally records for each tape, whether ist has been written by a B-type or E-type drive, and refuses to _continue_ to write a B-type tape on an E-type drive. You thus only need to set the FILLING tapes to READONLY, no need to set them all to READONLY or to define a new storage pool, as someone else mentioned. It is important, that the TSM server recognizes the new drive types. This is done by deleting and redefining the drives. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: reducing domain valuse
Michael Hull [EMAIL PROTECTED] schrieb: I can not guarantee that the following is true, but it is my experience. When an expire process runs, it reports the number of objects examined. From what I can determine, this is the number of inactive backup objects, which is the maximum number of objects that would be deleted by lowering the retention limits to keep only the active backups. good idea, but ... not true. I just did a test on a small server (4.1.2.0): tsm: TSM02select count(*) from backups where state='INACTIVE_VERSION' Unnamed[1] --- 325347 tsm: TSM02expi inven ANR0812I Inventory file expiration process 65 completed: examined 31689 objects, deleting 3258 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 errors were encountered. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Upgrading to 4.1
TSM moved the required files. The new $DSM_DIR is different. However, I seem to recall that one file didn't get moved automattically, I forget now which one. dsmserv.opt. This file was not automatically moved, when I upgraded a 3.1 server to 4.1 recently. But this does not contribute to Thomas' original question - he already installed 4.1 on the machine that runs the 3.1 server. I think, his migrate process should work. Reinhard Miles --- Miles Purdy System Manager Farm Income Programs Directorate Winnipeg, MB, CA [EMAIL PROTECTED] ph: (204) 984-1602 fax: (204) 983-7557 --- [EMAIL PROTECTED] 14-Jun-01 2:22:08 PM So the TSM installation moved all files to their new directories or did it keep the old ADSM file structure? -Original Message- From: Miles Purdy [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 2:38 PM To: [EMAIL PROTECTED] Subject: Re: Upgrading to 4.1 We just did the exact same upgrade, but it is even easier than what you outlined below. 1. do your backups 2. shut down the server 3. use smit to install the new version This is all we did and everything worked great! miles --- Miles Purdy System Manager Farm Income Programs Directorate Winnipeg, MB, CA [EMAIL PROTECTED] ph: (204) 984-1602 fax: (204) 983-7557 --- [EMAIL PROTECTED] 14-Jun-01 12:14:29 PM Platform: AIX 4.3.2 ADSM: 3.1.2.50 We have been testing 4.1 on a system that already has a 3.1 instance installed. We are now satisified with 4.1, and would like to migrate our 3.1.2.50 instance to 4.1. The manual indicates directions on how to do the migration at the time of installing the 4.1 software--a step that we've obviously already taken. I thought that what I would have to do is 1) do a full database backup of the 3.1.0.5 instance 2) copy my relevant files (dsmserv.dsk, etc.) to the new DSMSERV_DIR (/usr/tivoli/tsm/server/bin) 3) start the TSM 4.1 server with 'dsmserv upgradedb' 4) re-register all of my licenses Has anybody else gone through the process in this manner? Am I missing something? Any advice/tips/suggestions are welcome. -- Tom Thomas A. La Porte DreamWorks SKG [EMAIL PROTECTED] -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Mac 3.7 Errors
Can any body figure what this error is. DTcpipinterface::ciflush: Unknown Error Code ; rc = 268435559 sessRecvVerb: Error -50 from call to 'readRtn'. Just install Tivoli 3.7 on a Mac and Not sure what this error is. I would call Tivoli but dont think they care about Mac's to much. Any help is good help.. This seems to be APAR IC27847, which is corrected in 4.1.2.15 (IP22153_15). -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
DB reorganization (Was: Re: DISK reclamation?)
France, Don G, wrote: ... Tivoli db architect recently admitted it would be advisable to re-org the db once or twice a year, to defrag it. Who said that, when and where? Especially in the light of the recent discussions about DB reorganization (see subject Reducing/compressing the database), this would be important to know. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Reducing/compressing the database
Mark, as others already said, these utilities (DSMSERV UNLOADDB, DUMPDB, LOADDB and AUDITDB) in fact ARE documented and always have been (Appendix A in the 3.7 and 4.1, appendix D in the 3.1 admin ref.). They are poorly documented though, e.g. not saying anything about the required time, and not stating the possibility to restrict the AUDITDB on part of the DB, but that's what the recurrent complaints, at least in part, where about. Furthermore, you may come into a situation, where support advises you to perform these utilites. I once was there, but fortunately decided to perform a test on a copy of my production server at first. It turned out to last for several weeks, so I decided not to follow that advice. That was on version 3.1, things may have changed since then, but again: nothing official can be heared from Tivoli. Personally, I'm feeling very uncomfortable about that situation. And I think, complaining about it has nothing to do with whining. Reinhard Mark Stapleton ([EMAIL PROTECTED]) wrote: Thomas A. La Porte wrote: Is anybody else a little bit distressed that Tivoli's TSM administrator needs to seek this advice from the list, rather than from the developers of the product? I think I've read just about enough whining in this thread about how Tivoli 'distresses' people by not commenting on/explaining/helping with undocumented and proprietary commands. *Of course* there is no official documentation on undocumented UNLOADDB/LOADDB, SHOW, and the various undocumented flags to some commands. There seems to be some mania in our list about 'defragging' a database and how it is considered a cure for all TSM ills. The real world shows that 'defragging' any database has at best minor results, save in the most severely edited database. 99% of slow response problems stem from far more likely situations, such as poorly configured networks and bad TSM configurations. People should keep in mind that there is a reason why undocumented commands are undocumented. It's because they're buggy, unreliable, and in some cases, dangerous to your TSM installation. Anybody who would run UNLOADDB/LOADDB on a production box gets anything they deserve. If you've *got* to reach for the nirvana of defragging your database, consider running DSMSERV RESTORE DB from the OS command line; this is a documented procedure for which you can get support help if necessary. There. That should be enough flamage for one day. Sorry, folks; I've been subjected to the same basic complaint for the four years I've tracked this mailing list, and it was just time to say *something*. -- Mark Stapleton ([EMAIL PROTECTED]) -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: TSM/HSM problem writing to filesystem
I would also look into that direction. And: Is your filesystem large file enabled? I vaguely remember having read about possible problems, when a large file enabled filesystem is crowded with small files (and the stubs are small). Something in the sense, that free space actually exists but cannot be used. Might be worth to have a look at defragmentation? it looks like an OS problem maybe no more available inodes or file table entries ? of course if you can't even copy a file it's not a tsm problem... A 10:09 24/04/01 -0400, vous avez écrit : We are experiencing a problem writing data to our HSM-managed filesystem. The HSM-managed filesystem is on the same system as the server, which is running AIX 4.3.3, TSM Server 4.1.3, TSM Client 4.1.2. Although there is plenty of available disk space in the HSM-managed filesystem and it is nowhere near its migration threshold, we are experiencing errors when trying to create files in the filesystem. For example, hostnamecp SOL-002 sol cp: sol: There is not enough memory available now. hostname ./testlooper dd: write error: Not enough space Attempts to retrieve files off of the HSM tapes also result in an error: ANS9283K Tivoli Space Manager is recalling a migrated file. ANS9285K Cannot complete remote file access. I looked up ANS9285K in the Messages Manual - it says to check if the server has been disabled. The server is up and running and has been running backups successfully, including those on the HSM-managed filesystem. There is 500 Megabytes of free memory on the server just now. Errors don't occur for every file in the filesystem. The errors just started happening yesterday. There are no errors in errpt, console log, or dsm logs. Our db and log are not full, there are available tapes. Any ideas what the problem/solution might be? -- Mary Stephenson [EMAIL PROTECTED] Academic Computing Network Services Florida State University - * - * - * - * - * - * - Mes idees n'engagent que moi (vieux proverbe du Net) Thierry ITTY eMail : [EMAIL PROTECTED] FRANCE -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Special characters Bug in Linux Klient as well?
Hello, this is APAR IC29458, which is CLOSED, temporary fix: "Use 4.1.1. client or do not use file names with german umlaute and other country specific characters." The APAR refers to the 4.2 Linux client, which will be MBCS enabled, but does not tell, when it will come. What makes this bug really ugly is the fact, that it does not show up in the backup summary. You only see it when you look at the dsmerror.log, or try to restore such a file. Hello, on a Linux system which servers as a Samba server we see the following message in the log: 15.04.2001 02:10:24 fioScanDirEntry(): Object '/usr/share/doc/sdb/de/html/keylist.AUSWHLBAR.html' contains unrecognized symbols for current locale, skipping... Is this the bug which is solved for Windows in Version 4.1.2.12? Is there anything else we should do to allow TSM to backup files which contain umlauts in the name? Best regards Gerhard --- Gerhard Rentschleremail:[EMAIL PROTECTED] Regional Computing Center tel. ++49/711/685 5806 University of Stuttgart fax: ++49/711/682357 Allmandring 30a D 70550 Stuttgart Germany -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: MOVE DATA seems to empty volume but still shows full
Before doing that, I would simply try tsm: ADSMaudit volume bqy624 fix=yes Suad We're running TSM 3.7.4.4 on NT and see a similar thing periodically. Try taking the server down and running the following: DSMSERV AUDITDB DISKSTORAGE FIX=YES Depending on the size of your database, this may take a while. We usually encounter problems in virtual volumes created by server-to-server comms. In this case, we run DSMSERV AUDITDB ARCHSTORAGE FIX=YES This takes about an hour for a 7Gb database. NB These are unsupported options so make sure you have a database backup beforehand. Regards Neil Schofield The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682 -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
DST fix for Alpha?
Hi, we have some huge NT on Alpha clients, which are using TSM 3.7.2., hence I'm in desparate need for the DST fix for them. Where can I find it? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Patch 4.1.2.12 - Experiences
I just applied patch 4.1.2.12 to one of our Windows clients having lots of "umlaut" files. The cleanup utility worked as described, with the exception of needing THREE runs, until no more "Incorrectly cased object" messages occured in the sequencing view run. The cleanups issued lots of ANS1228E and ANS1304W messages. Is this normal behaviour? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: ADSM-L Digest - 3 Mar 2001 to 4 Mar 2001 (#2001-62)
Louis, yes, this error is known, and I have reported it to Tivoli more then 3 months ago (problem # 37565). The problem is still open. This is why I'm saying, that a working TSM client for Macs currently does not exist. Apparently, the problem only occurs when lots of files are restored (e.g. when restoring a folder) and the backups have left the disk pools, hence tapes have to be mounted. It is NOT limited to backups made by older client versions, though APAR IC27847, which I was referred to, states this. In one case, I could circumvent the problem by creating a backup set and transfering it to client. Restore from this backup set worked fine. Hello, I am hoping that the following error for a Restore operation is known to someone on the ADSM listserver: Running the TSM Mac client 4.1.2 on MacOS9.1 with an AIX-RS/6000 Server : 05-03-2001 16:51:33 DTcpipInterface::ciReadAvailable: UnKnown Error Code : rc = 268435556 05-03-2001 16:51:33 sessRecvVerb: Error -50 from call to 'readRtn'. 05-03-2001 16:51:33 sessRecvVerb: Error -50 from call to 'readRtn'. 05-03-2001 16:51:33 mpDestroy: Memory Pool #14 doesn't exist 05-03-2001 16:51:33 ANS1809E Session is lost; initializing session reopen procedure. 05-03-2001 16:51:40 ANS1811S TSM session could not be reestablished. Administrator is sure that the Server is not at fault!? Thanks -- Louis Giannone Max Planck Institut fuer Plasmaphysik Boltzmannstrasse 2, D-85748 Garching bei Muenchen, BRD. e-mail: [EMAIL PROTECTED] Tel.0049 - 89 - 3299 1499 FAX 0049 - 89 - 3299 2584 Office 0049 - 89 - 3299 1963 http://www.rzg.mpg.de/~giannone/ -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Complaints (Was: Window Client - Time Change bug)
Wanda Prather wrote: Sadly, after being a rabid fan of TSM for several years now, Me too. I have finally started recommending to some people that they NOT install it. ME TOO! The first time, I recommended NOT to install the TSM client was, as luck would have it, yesterday. It was a MAC; who needs backup software, if it is unable to restore? (As a colleague pointed out: the service we offer is not backup, it is RESTORE.) ... Tivoli Marketing is making it impossible to champion this product any more. The current licensing scheme is so bizarre that you can't get the same quote ... While we are at it: What are the costs of a TSM client on an end-user workstation? Tier 1 would mean 7 management points, but somebody told me, that the tier scheme only applies to servers, and that an end-user workstation costs 4 points only. Anyway, the management point scheme only makes sense to me, if it is possible, to just tell the server the number of points I have bought, and not having to register different license types (where it is even not possible to distinguish the client tiers). The server should know, how many points are needed. If not, why should I worry? It's a shame, because I know how much good work has gone into the server end of this product, and I think it is still the best of breed. But I think there may be a lot of sites, including this one, where there will be serious consideration of an alternative product when the contract comes up for renewal. My opinions and nobody else's Mine too, and it is good to hear that others feel the same ... -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Serios Situation - Related to Recovery Log
Mahesh, perhaps you are just too impatient? I have also seen startup times in the range of 15 minutes, and our DB is only half the size of yours, the recovery log is much smaller than yours. This was on a G40, currently on our F80 it is much faster. Did you watch the CPU time consumption of the dsmserv process? Hello WIZs, It has happened again. Last time it happened on 16/1/2001 and the Full Database had to be restored back. This time also, the whole DB was restored in order to bring the server to the normal situation. Description : ADSM Server not starting When I manually run 'dsmserv' command , it just stucks with the messages displayed as following: - Cut Here -- %dsmserv ANR7800I DSMSERV generated at 23:08:28 on Apr 22 2000. Tivoli Storage Manager for AIX-RS/6000 Version 3, Release 7, Level 3.0 Licensed Materials - Property of IBM 5697-TSM (C) Copyright IBM Corporation 1999. All rights reserved. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation. ANR0900I Processing options file dsmserv.opt. ANR0200I Recovery log assigned capacity is 4144 megabytes. ANR0201I Database assigned capacity is 76088 megabytes. ANR0306I Recovery log volume mount in progress. -- I have waited for Half an Hour and there seemd to be no disk activity. I have checked dsmserv.dsk and it was found to be OK. I tried with 'dsmserv extend log log file name 401mb, but in vain. Ultimately DB was restored which took 7 Hrs. When we restore the DB, it firsts formats the recoery log. Is there any way I can format the recovery logs without going in for restoring back the full DB.? Our Database size is : 76 GB OS : AIX 4.3 TSM Version : 3.7.3.0 Any hint would be greatly appreciated. IBM's first suggestion is to upgrade the version. Regards Mahesh -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Migration doesn't end
Just a guess: I have seen situations, where a volume (disk or tape) was empty according to MOVE DATA, and not empty according to DELETE VOLUME. An AUDIT VOLUME helped in that situation and takes much less time than a complete AUDITDB. Ok, our problem is back! Now, it does bring the pool to 0%. Ken and John, can you verify if we are having the same problem? At the point when migration is not moving any data, does your CPU Utilization go up to 100% and stay there until you raise the Migration values? I have this problem now, it's a holdover from my ADSM 3.1.2.55. The upgrade didn't make that go away. The pool is actually empty, I wonder what is causing it to think something is there. I have not paid attention to the CPU usage when this is going on, however I have done other things with the server during the migration and it seems to answer up normally. In the past I also had to auditdb to fix the problem. Unfortunately the last time that took forever so I can't afford to run it at the moment. I just let it go, when migrate off runs it quits. Geoff Gill NT Systems Support Engineer SAIC Computer Systems Group E-Mail: [EMAIL PROTECTED] Phone: (858) 826-4062 Pager: (888) 997-9614 -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Can Mac clients restore ?????
Hello, since almost 2 months I have an open problem (#37565): Some of our Mac clients (MacOS 9) have upgraded to TSM 3.7 and later to TSM 4.1 and are unable to restore (under both versions). Some few files are restored, but then the session dies, showing DTcpipInterface::ciReadAvailable: UnKnown Error Code : rc = 268435556 in the error log. The server is TSM 4.1.1 on AIX 4.3. This looks similar to APAR IC27847, except that it affects ALL backups (including new ones), not only backups made by ADSM 3.1. Besides the long time this problem is open now, what surprises me is that I cannot remember having seen any postings in this regard here. I am wondering, whether there are _ANY_ 3.7 or 4.1 Macintosh clients out there, which can successfully restore more than a few files. And if so, what is the environment? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Backup Retention Period
Cameron McDonald writes: Also, don't forget that rebinding only occurs on 'backup' data not 'archive' data. ? Where do you have that information from? To the best of my knowledge, it is wrong. Rebinding DOES also affect archive data. -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Putting ADSM config files in a separate directory
Hi Gerhard, the executable "dsmlicense" has also to be in the seperate directory, otherwise the license manager will not come up. This is an experience I made when installing TSM 4.1.1, and it took some time until I figured out what was going on. I have also put the .lic files there, just for conveniance. It should be possible to specify a path when registering the licenses. Regards, Reinhard Gerhard Rentschler writes: Hi, I'm about to move my ADSM Server to a new system. I thought it would be a good idea to have the config files no longer in /usr/lpp/adsmserv/bin, but in a separate directory, e.g. /adsm/config. I know I have to use environment variable DSMSERV_DIR o point to the new directory. Also, because dsmserv assumes a few files like nodelock to be in the directory where dsmserv is started in I have to do a cd before the start of dsmserv. Now I would like to have a comlete list o files which have to be moved to the new directory. I know the following files: dsmserv.opt volhistory devconfig nodelock dsmserv.dsk Are there any others? What happens if I do a register license? Where does this command look for the *.lic files? Another question in this context. I may have to run 2 different ADSM servers on the same hardware. It may be helpful to run both servers not as root but with different userids. This would allow to protect the servers file against access by the other. Does anyone have experience with such a setup? Best regards Gerhard --- Gerhard Rentschleremail:[EMAIL PROTECTED] Regional Computing Center tel. ++49/711/685 5806 University of Stuttgart fax: ++49/711/682357 Allmandring 30a D 70550 Stuttgart Germany -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: HSM disaster: all backups expired
Richard Sims writes:
last weekend, the backup of our biggest HSM filesystem (AIX 4.3.2,
ADSM 3.1.0.8) expired all files !!!
Reinhard - My sympathies on that ugly problem. It superficially sounds
thanks
as though the file system was not mounted, such that the
backup found just the empty mount point directory and worked that.
It looks like that, but there is absolutely no indication pointing in
that direction.
I would hope it not the case that HSM asked for file system info for
the backup and, because of a file system problem at the time, got none,
and kept going.
I fear, that this is actually the case.
The backup log from that time may provide clues.
No. When backup started, it immediately began expiring the files.
The EINTR errno on statfs() is not a documented errno for that system
call, so its meaning in that context is undefined. I have not experienced
it in my experience with programs utilizing statfs().
Looks like you're stuck having to perform a complete backup again.
Something peculiar transpired in your system during that time.
Perhaps the AIX Error Log will have info on it, or the dsmreconcile
or dsmautomig logs will reflect some conditions.
No.
If no AIX reboot occurred since that time, I wonder if vestiges of
the condition linger, and may be affecting your backup processing now.
I did a reboot today, after installing TSM 4.1.
- The new backup process is now recalling all files, although I expected
it to simply make a copy within the TSM server. Why? ("Migration
Requires Backup?" is set to "No".)
With the HSM and backup storage pools within the same server, backup
is *supposed* to copy the data within the server, without recalling
it to the client file system. (If the data has not yet been migrated,
or is premigrated, backup will occur from the filesystem copy of the
file.) Files marked for read-without-recall will be backed up through
the client in that manner; but files have to be individually marked
that way, and I doubt that it applies in your case.
With the new client software and after rebooting the machine, the situation
has not changed. Files to be backed up are still recalled.
I have seen the correct behaviour (backup without recall) some time ago.
The server was ADSM 3.1 then, now it is TSM 4.1; perhaps that makes the
difference. A note in the HSM guide makes me nervous:
"If you migrate and back up data to tape, use separate tape
drives for backup and migrated data."
I hope, this does not mean, that I have to define different libraries
for backup and HSM usage. This would not make any sense to me, but
somewhat makes me sceptic ...
Anyway, I have opened problems on these two matters. Let's see what
comes out of it.
Regards,
Reinhard
--
Reinhard MerschWestfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
HSM disaster: all backups expired
Hi,
last weekend, the backup of our biggest HSM filesystem (AIX 4.3.2,
ADSM 3.1.0.8) expired all files !!! I do not know the reason; the
only hint I get is one line in dsmerror.log:
TransErrno: Unexpected error from fioGetFS:statfs, errno = 4
My main concern now is: how do I handle the situation? Since the
backups are marked inactive in the TSM server (4.1.1), all files
have now to be backed up again. Having 465 GB in ~10 files,
this will take a lng time.
- Is there any top secret and well hidden command, that lets me switch
the ACTIVE-flag on again in the TSM DB?
- The new backup process is now recalling all files, although I expected
it to simply make a copy within the TSM server. Why? ("Migration
Requires Backup?" is set to "No".)
Any hints and tips are welcome.
--
Reinhard MerschWestfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Recovery Log Problems while in Normal Mode
Hi, contrary to the other responses you got so far, I would think that 1.5 GB log size should be big enough for a 13.5 GB DB if you are doing daily DB backups. (Ours is 0.8 GB , Db size ist 38 GB.) Was EXPIRE INVENTORY running when the server crashed? Perhaps you had the same problem as we had last weekend: Our recovery log went full (but did not crash the server). The reason: Due to the Daylight Savings Time (DST) error in the Windows TSM client, many of our Windows clients did full backups after the DST switch. So, many backup copies became inactive and were expired through the EXPIRE INVENTORY run last weekend, causing an unusually big amount of change activity against the DB, which all had to be buffered in the recovery log during DB backup. Reinhard Wood, Dwight - BSC writes: My recovery log filled up and crashed the server this morning. I have the recovery log in "Normal" mode - NOT "Roll Forward" mode. I was under the impression that the recovery log would not fill up and crash the system while in normal mode. The log is 1.5 GB and the DB is 13.5 GB. We do a full DB backup once a day, sometimes twice. When I restarted the server the log showed up as 0.1% utilized. Does anyone have any idea as to what might cause the log to fill up? I am running TSM 3.7.3 on Solaris. Thanks, -Dwight -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Unload /Reload timings and efficacy
John, from my experience with ADSM 3.1.2 on AIX, I do not think that it can be done within 12 hours. The DUMPDB is quite fast, but the LOADDB takes a lot of time (more in the order of days than hours). And it may require much more space than the original 18 GB. But again, this is my ADSM 3.1.2 experience. Perhaps things are totally different with TSM 3.7. I would love to hear that they are, but nobody could assure me so far. Even more, I tend to doubt the wisdom of that recommendation. I never heard, that performance problems could be resolved by a DB reorganization. Reinhard John Naylor writes: Hi, I have been recommended a compress of the database ie. unload/reload as a cure for slow restores with large Novell data servers. Has anybody been through this, and can confirm my estimate of 6 hours approx for the unload reload part of thr process. We are OS390, TSM 3.7.20.0 The database is 84.5% occupied of 18.1gb 8 logical volumes ie : Total Usable Pages: 4,764,672 Used Pages: 4,027,026 Also any feelings on whether this is likely to make a real impact on the database access element of the restores. Thanks, John Has anybody been there, done it, got the figures. I am looking for a nice warm feeling. I cannot have TSM unavailable for more than 12 hours max. Thanks ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group. ** -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: ANR9999D asutil.c(218): Pool id 0 not found.
Strange, I am seeing a similar message during start of the server (3.1.2.57), but never saw it during a restore. I always contributed it to a problem we are known to have in our DB. (I could not afford to run the suggested DUMP/LOAD/AUDIT DB so far.) And, what a coincidence, we are also using ADSM to backup our DFS (dsmcdfs with VIRTUALMOUNTPOINT definitions) ... Sorry of beeing not able to supply more help. But, could you please tell me, if and how you resolved the problem? Horst Scherzer writes: When I try to restore a (DFS) directory structure (backed up by means of Virtual Volumes), I get the following error: 10/23/00 09:25:05 ANRD asutil.c(218): Pool id 0 not found. 10/23/00 09:25:05 ANR1165E Data-integrity error detected for file in storage pool (0): Node DCEDFS2, Type Backup, File space /.../dce.univie.ac.at/fs/unet/user03, File name /a403/profile/Application Data/Microsoft/ Address Book. Has anyone seen this error before? SW: AIX 4.3.2+, TSM Server 3.7.3, ADSM Client 3.1.0.8, (dce 2.2.0.6) Tia, -- Horst SCHERZER mailto: [EMAIL PROTECTED] Zentraler Informatikdienst Uni-Wien Fax: (+43 1) 4277 x9140 Universitaetsstr.7 Phone: (+43 1) 4277 x14053 A-1010 Vienna, Austria URL: http://mailbox.univie.ac.at/~sc begin:vcard n:Scherzer;sc tel;fax:4277-9140 tel;work:4277-14053 x-mozilla-html:FALSE url:http://mailbox.univie.ac.at/~sc org:Zentraler Informatikdienst Uni-Wien adr:;;Universitaetsstr.7;A-1010 Wien;Oesterreich;; version:2.1 email;internet:[EMAIL PROTECTED] title:Systems Programmer fn:Horst Scherzer end:vcard -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
3583 support
Hi, in the list of devices supported by TSM I am missing the "3583 Ultrium Scalable Tape Library". Does anybody know, if and when this support will come? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Re: Determining Capacity on ADSM?
Shekhar, are the cases o.k.? I bet, it should look like select count (*) from volumes where devclass_name='STK9710' ^^^ Regards, Reinhard Shekhar Dhotre writes: tsm: TSMselect count (*) from volumes where devclass_name='stk9710' Unnamed[1] --- 0 tsm: TSMselect count (*) from drmedia Unnamed[1] --- 49 tsm: TSMselect avg(EST_CAPACITY_MB) from volumes where devclass_name='stk9710' Unnamed[1] whats wrong with first and third query? or not applicable to stk? - "[EMAIL PROTECTED]/P=Internet/A= /C=us" on 09/19/2000 01:23:01 PM Please respond to "[EMAIL PROTECTED]/P=Internet/A= /C=us" @ X400 To: "[EMAIL PROTECTED]/P=Internet/A= /C=us"@X400 cc: Subject: Re: Determining Capacity on ADSM? How do I determine how many physical slots my 3494 library has? mtlib -l /dev/lmcp0 -qL | grep cells How do I determine how many tapes are offsite? a) select count(*) from volumes where stgpool_name='BACKUP3590_OFFSITE' (where a storagepool is used for offsite.) b) select count(*) from drmedia (where DRM is in use.) c) select count(*) from volumes where access='OFFSITE' (where you set the access or use DRM.) Note: tapes may be in transit to-and-from offsite. Also, db backups are not in the volume table. How do I determine how many tapes total I have? select count(*) from volumes where devclass_name='MAGSTAR3590' (where your device class name is MAGSTAR3590.) How do I determine the average capacity per tape? select avg(EST_CAPACITY_MB) from volumes where devclass_name='MAGSTAR3590' -- Richard -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
Long running expiration / Object already expired
Hello, on our ADSM server (3.1.2.57 on AIX), EXPIRE INVENTORY is currently runnning much longer than usual and issuing a lot of messages of the form ANRD imarqry.c(2004): Object 0.a3f74b4 of type 1 is already expired Has anybody seen this and know what that means? -- Reinhard MerschWestfaelische Wilhelms-Universitaet Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583 E-Mail: [EMAIL PROTECTED] Fax: +49(251)83-31653
