From owner-networker@LISTSERV.TEMPLE.EDU Sun Sep 10 16:34:17 2000 Return-Path: Received: from listserv.temple.edu (listserv.temple.edu [155.247.166.105]) by mailhost.nmt.edu (8.10.2/8.10.2) with SMTP id e8AMYFv11896 for ; Sun, 10 Sep 2000 16:34:15 -0600 Received: (qmail 24104 invoked by uid 0); 10 Sep 2000 22:35:02 -0000 Received: from listserv.temple.edu (155.247.166.105) by listserv.temple.edu with SMTP; 10 Sep 2000 22:35:02 -0000 Received: from LISTSERV.TEMPLE.EDU by LISTSERV.TEMPLE.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 731520 for NETWORKER@LISTSERV.TEMPLE.EDU; Sun, 10 Sep 2000 18:34:59 -0400 Delivered-To: NETWORKER@LISTSERV.TEMPLE.EDU Received: (qmail 24843 invoked by uid 0); 10 Sep 2000 22:34:43 -0000 Received: from agora.rdrop.com (0@199.2.210.241) by listserv.temple.edu with SMTP; 10 Sep 2000 22:34:43 -0000 Received: from joan.burling.com (root@ppp-d7.rdrop.com [199.2.212.40]) by agora.rdrop.com (8.8.7/8.8.7) with ESMTP id PAA00343 for ; Sun, 10 Sep 2000 15:32:41 -0700 (PDT) (envelope-from llywrch@agora.rdrop.com) Received: from joan (IDENT:geoff@joan [127.0.0.1]) by joan.burling.com (8.9.3/8.9.3) with ESMTP id MAA08515 for ; Sun, 10 Sep 2000 12:03:55 -0700 X-Sender: geoff@joan.burling.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 10 Sep 2000 12:03:55 -0700 Reply-To: Geoff Burling Sender: Legato NetWorker discussion From: Geoff Burling Subject: [Networker] Networker FAQ -- Part 7 of 7 To: NETWORKER@LISTSERV.TEMPLE.EDU Status: RO Content-Length: 11789 Lines: 274 I've been lurking here for the last couple of months, & have noticed quite a few questions that should be answered in the FAQ. I checked with the folks who said they'd carry this chore on, & since they had no objection, & although I'm no longer responsible for it, I'm reposting the FAQ one more time. I hope this answers a few questions & save a little bandwidth. Geoff Burling =============================================================== Mike Myers submits (28 Mar 2000): There seems to be an issue with the recommended tuning parameters for high speed networks from Sun (eg. GB Ethernet and ATM). Specifically the tcp_xmit_hiwat and tcp_xmit_recv tunable which Sun recommends (info doc 17416, which appears to be quoting the answer book) be set at 64K each. These appear to be tickling a bug in the TCP/IP stack when set this high. It will lower your throughput a little to return them to their default values of 8K but it has greatly increased the reliability of our environment. Another person (alain.gourves@paribas.com) sent me the following which may also address the problem (or at least did for them). This was after I sent him our experiences with returning to defaults: To correct our problem, we tuned the TCP/IP parameter tcp_conn_req_max_q up to 256 (128 by default) and left tcp_recv_hiwat and tcp_xmit_hiwat at 65635. At this site "http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html", I found a great document for tuning. Sun has closed this because the original organization that opened it was happy with the work-around (reducing back to defaults). We're looking into getting this reopened and actually fixed. Another hang issue that may or may not be specific to the Solaris platform (which is what we run on) are the "Nsrmmd polling interval" and "Nsrmmd control timeout" intervals. These only apply to Storage nodes (it controls how often it checks to see if the nsrmmd is still running) and we ran into this hang after adding a new storage node at the end of a WAN link. We've changed ours from the default (3 and 5 minutes I believe) to 10 minutes each. This has solved some problems which were destabilizing our environment. Apparently this is addresses in the upcoming release of Legato (it is a known bug). Q. After upgrading to Solaris 2.7 (Sun Ultra Enterprise 1), I cannot successfully install and start the scsi driver. Networker can not use the robotic peripherals, but it can see the drives. What's wrong? A. Bill Duncan originally reported this problem. Joseph Oritz reported (16 June 2000) that that there was a specific patch required from Sun to make the lus driver install. Bill replied: Thanks, Joseph. That was one of the recommendations by Legato Support even though our Sun has an S bus, not PCI. We applied Sun patch 107147-05 as requested by support, then worked our way through the 'fix' that was supplied on their website but it still would not work. In this case, Avi Koski apparently offered the correct solution: I had the same problem on an "AXi UltraSPARC IIi 440MH" machine with PCI bus and Solaris 2.7 where the Legato "lus" driver would not properly install. It seems that the link of /dev/lus is not built, in IPC machines, but... the device itself in /devices/.../lus@0,0:0 exists. After issuing a manually link, by : ln -s /devices/.../lus@0,0:0 /dev/lus the problem was solved, and now both commands 'inquire' and 'jb_config' work fine, when trying to automatically detect the JukeBox. 9.5 Networker BSMs. A log file is kept at /nsr/applogs/xbsa.messages. In my limited experience, this should be readable & writeable by the world. 9.5.1 Informix Q. How do I restore to a different server than the one I backed up? A. Richard Spitz posted (11 May 2000): I know it is possible to restore an "ontape" backup to a different machine, but then you have to make sure that the Informix environment is exactly the same as on the original machine, i.e. the same paths leading to the chunks Informix uses, same size of chunks etc. I assume that the same holds true for restoring an onbar backup to a different machine. Thomas Cusack added (12 May 2000): everything you say is correct and in addition you need to have run a "whole system backup" which allows "imported restores", also the servernum in the onconfig must be the same. The chunk paths do need to exist as same size, but the environment does not matter other than that. 9.5.2 Microsoft SQL A. Joseph Oritz posted (31 March 2000): To cover the basics in order since this question seems to get repeated frequently here: CLIENT SIDE ========== If you are using version 1.x of the BSM, you set the appropriate variables in the nsrsql.bat file. It contains variables for the nsr server, pool, group, etc. but they are all normally commented out. You have to adjust them to your environment and uncomment them. If you are using version 2.x of the BSM, then everything on the client side gets set up via the BSM SQL User GUI. There is NO client nsrsql.bat file. If you upgraded from 1.x to 2.x BSM, be sure you DELETE the old nsrsql.bat file after you get your environmental settings out of it. If you're backing up SQL 7.0, then you must use the 2.x version of BSM for SQL. If you want all SQL data going to the SQLData pool (I'm assuming you also want the transaction logs, if you're also doing Incrementals on the SQL databases, going to the same pool), for the 1.x version BSM, you would set both the NSR_DATA_VOLUME_POOL and NSR_LOG_VOLUME_POOL variable to SQLData. If you're using the 2.x version of BSM, then you would set both the BSM_SQL_DATA and BSM_SQL_LOGS variables to SQLData which matches your pool definition on the server. If you want Incrementals, transaction logs separate, then you would need a pool set for those as well and the NSR_LOG_VOLUME_POOL or BSM_SQL_LOGS variable would be set to the name of that pool for the SQL Incrementals. With SQL 7.0, the client setup gets a bit more involved because you also have to get a specific ID set up in the SQL database with the appropriate settings and permissions and password. This info. is then entered via the BSM 2.x SQL User GUI. SERVER SIDE =========== On the server side, set up the necessary schedule(s) to provide for the Full, Incr., etc. backup levels on the appropriate days. I'm assuming you have 2 client definitions for your SQL client. One definition, which is the client's "base" definition with a save set of ALL, and which is probably a member of the Default group. Then you have a 2nd definition which belongs ONLY to the SQL group (NTSQL in your case) and has a save set spec of MSSQL:. If you're using the 1.x version of the BSM, then you reference the nsrsql.bat in the Backup Command field of the client definition. If you're using the 2.x version of the BSM, then you reference the nsrsqlsv command, with any appropriate parameters, in the Backup Command field of the client definition. Do NOT specify any directives for the MSSQL client definition. POOL SIDE ========= Remember that pools are simply "glorified" data filters that sort data based on 4 criterion in descending order of precedence: 1) Group Membership 2) Client Name 3) Save Set spec 4) Backup Level(s) The pool you set up for the SQLData would have a matching tape label (unless you're using barcodes with matching turned on) and the backup level would be set to FULL. You would also have ONLY the SQL Group selected (NTSQL in your case). If you're also going to direct Incrementals/transaction logs for SQL to this same pool, you would additionally select backup levels 1 and INCR. You would also have the SaveIndex option turned on. Somewhere along the line you may have missed a setting. Data usually goes to the Default pool when it fails to meet the criteria of any other pool definition. 9.5.3 Oracle Q. We can not let RMAN talk to networker correctly. The saveset starts on the Networker server, but it gets no data and RMAN quits. A. Karlheinz Heger posted (22 May 2000): Here are some hints to work with BMO on NT. Did you stop and start Oracle services after installation of BMO ? Are you sure that your recovery catalog is o.k. and you have registered the target db correctly ? Running RMAN requires some settings in your environment (ORACLE_HOME, ORACLE_SID, ...). Otherwise you will get strange results. "nsrdmo" shows you what you really need. When you have not set the ORACLE_SID in your environment, Oracle always reads the default ORACLE_SID from the Windows registry. "ORCL" is always set there because Oracle installer creates an DB with SID "ORCL" as the default. Q. After installing BMO with Solaris 2.7 (64-bit) & Oracle 8.1.5 (64 bit), when we start the oracle svrmgrl we get the following shared library error ld.so.1: oracleprod8i: fatal: libobk.so: open failed: No such file or directory ld.so.1: oracleprod8i: fatal: libobk.so: open failed: No such file or directory and svrmgrl exits. A. ``fg" replied (20 June 2000) You should read the release information and make sure the Legato version you are using supports the verision of Oracle you are running. Also check for 64 bit vs 32 bit support in both Oracle and SUNOS. Check for required patches. I recently started using the Legato Oracle NMO 3.0 and it required Oracle 8.0.5 be relinked with a new library from Legato. Different versions require different actions. Lastly, there are significant differences between Legato Oracle BSM 2.x and Legato Oracle NMO 3.x so you should include the Legato Oracle module version in your posts. Sorry I'm not more help. -fg =====>> I am not an Oracle/Legato backup expert yet <<===== 9.5.4 Sybase Note: The Sybase BSM is only a storage manager for the Sybase Backup Server. The BSM will start the backup or restore processes, & will not exit until the process finishes -- although monitoring the processes thru nwadmin or nsradmin will report completion before either nsrsybsv/nsrsybrc have finished. Some tips the FAQ maintainer learned the hard way: 1. nsrsybsv/nsrsybrc must use an account that a) has operator or sa roles, and b) has permission to use the database that will be backed up. The executables need to do a select on the database to see if the logs and the data are on different segments and an incremental backup is permissable. If the database is contained on contiguous segments -- or within one -- then nsrsybsv/nsrsybrc will start without error. 2. The value of $SYBASE must be identical on the server backed up and on the target server. This variable is the path to the location of the interfaces file. 3. Many error messages come directly from the Sybase Backup Server. These are listed at http://sybooks.sybase.com:80/onlinebooks/group-as/asg1200e/svrtsg/@Generic__BookView *** END of FAQ *** -- Note: To sign off this list, send a "signoff" command via email to listserv@listserv.temple.edu or visit the list's Web site at http://listserv.temple.edu/archives/networker.html where you can also view and post messages to the list. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=