home *** CD-ROM | disk | FTP | other *** search
/ ftp.seagate.com / 2014.07.ftp.seagate.com.tar / ftp.seagate.com / pub / palindrome / technote / tn9502.asc < prev    next >
Text File  |  1995-04-12  |  9KB  |  239 lines
  1.  
  2. TECHNICAL NOTE : ORACLE FOR NETWARE BACKUP USING THE PALINDROME TSA 
  3. VERSION NUMBER : 1.0  
  4. VERSION DATE   : 10 Mar 95
  5.  
  6. PURPOSE OF THIS TECH NOTE
  7. =============================================================================
  8.   To offer possible solutions or work arounds to common problems 
  9.   encountered when using the Palindrome Oracle TSA.
  10.  
  11.  
  12. CONTENTS
  13. =============================================================================
  14.   1. Overview
  15.  
  16.   2. General server tuning
  17.   
  18.   3. Verifying the Oracle TSA is set up correctly
  19.   
  20.   4. Problems & solutions
  21.   
  22.   5. Where to locate updates mentioned in this tech note
  23.   
  24.   6. Information to gather before calling for support     
  25.   
  26.   7. Issues with specific versions of Oracle              
  27.       
  28.  
  29. 1. Overview
  30. =============================================================================
  31.   Oracle is a relational database that runs on several different 
  32.   platforms. Palindrome's TSA protects Oracle 7.x running on a Netware 
  33.   server. Prior to the release of this TSA, the Oracle database had 
  34.   to be shut down to be backed up by our software. This causes down time 
  35.   for the Oracle server, which in many cases is run 24 hours a day. 
  36.   Palindrome's Oracle TSA is able to backup the Oracle database while it is 
  37.   running. 
  38.  
  39.  
  40. 2. General server tuning
  41. =============================================================================
  42.   The same updates that can be applied to the server for our 3.1A NLM 
  43.   software are also applicable here. The patches are :
  44.   STRTL3, LIBUP4, LANDR3 & TSA0694. All of these are specific to 
  45.   the version of Netware. These are the latest patches available & 
  46.   subject to change with newer versions.
  47.   
  48.   Make sure that you have used the updated files from the Oracle disk :  
  49.   PNAVOL.EXE, PNAREST.NLM, PNABACK.NLM, PNAUTIL.NLM.  
  50.   All of these files should be dated 10-21-94.
  51.  
  52.  
  53. 3. Verifying the Oracle TSA is set up correctly
  54. =============================================================================
  55.   We support all versions of Oracle 7.0x, however we have 
  56.   not tested the TSA with Oracle 7.1 which was recently released. 
  57.   Oracle 7.1 allows multiple instances of a database to run on a 
  58.   server which is not supported.
  59.  
  60.   We need to make sure the Archivist user is created on the file 
  61.   system & database of the Oracle server & given the rights we need. 
  62.  
  63.   There is a list of the minuimum rights in the Oracle database on 
  64.   page 2-8 of the TSA book. A simple solution is to grant the Archivist 
  65.   user DBA rights which is equivalent to unlimited rights.
  66.  
  67.   Next the DATABASE LOG MODE should be set to ARCHIVELOG 
  68.   & the AUTOMATIC ARCHIVAL should be set to ENABLED. This is 
  69.   discussed on page 2-9. You will need to un-remark 3 
  70.   lines in the INIT.ORA file which is detailed on page 2-10.
  71.   This is to PERMANENTLY turn on AUTOMATIC ARCHIVING, akin to adding 
  72.   a line to AUTOEXEC.NCF, every time the database is brought up.
  73.  
  74.   Both TSAPORA & the Netware file system TSA have to be loaded on the 
  75.   server.
  76.  
  77.  
  78.  
  79. 4. Problems & solutions
  80. =============================================================================
  81.   The current shipping TSA cannot determine the path of the control file 
  82.   when it is replicated. Replicating the Control file is done by adding a 
  83.   line to INIT.ORA that contains the path of BOTH control files. The Oracle 
  84.   TSA takes, both paths as 1 complete string (concatenated the paths) and 
  85.   causes the following:
  86.      
  87.     BS-28    Unable to read file <tablespace name>
  88.       fffa0406 The SMS API <NWSMTSReadDataSet> has failed.
  89.                 The reason is <Oracle failed to parse an alter database
  90.           backup controlfile call.>.
  91.  
  92.  
  93.   ORA-1580 is the error reported on the ORACLE console / ALERT.LOG
  94.   
  95.   There is a updated TSAPORA.NLM which was written to fix the 
  96.   above problem. ORACL-UP.ZIP with a password of AMOCO. 
  97.  
  98.   ===============================================================================
  99.   
  100.   If Oracle is configured in the INIT.ORA to refer to the control 
  101.   files location by a user defined variable Palindrome will report the 
  102.   following. [ A user defined variable is any variable other than 
  103.   a system defined one, example of system variable   RDBMS70 ] 
  104.   
  105.   NOTE:           (1 of 2)   BS-28          Backup Session Exception
  106.   DESCRIPTION:    Unable to read file <[AAFDLSF1.Oracle Database
  107.           System]AAFDLSF1/AAFDLSF1\SYSTEM>.
  108.   
  109.   WARNING:        (2 of 2)   SMS-fffdfff2   SMS API Exception
  110.   DESCRIPTION:    The Storage Management Services API <NWSMTSReadDataSet>
  111.           has failed. The reason given is <>.
  112.   
  113.   
  114.   The problem is that the archive log path Palindrome gets from Oracle does 
  115.   not give a full path, but rather just a filename. This is due to the fact 
  116.   that the TSA does not use a user defined variable to locate the path of 
  117.   the archived log files. Palindrome can't get a full path to the archived 
  118.   log files, thus the read errors during backup.
  119.   
  120.   
  121.   The following is an example of a user defined variable, %ORADUMP% , and how 
  122.   it can be changed to resolve the above problem
  123.   
  124.   
  125.   Solution 1:
  126.        Put a full path in the INIT.ORA file:
  127.   
  128.   old...                  
  129.        log_archive_dest = %ORADUMP%\archive\  #
  130.               ^^^^^^^^^
  131.   change to...  
  132.        log_archive_dest = SYS:ORACLE\TRACE\archive\  #
  133.   
  134.   For this to take effect you will need to close down the instance then restart the 
  135.   database and run the backup.
  136.   
  137.       
  138.   The next two solutions are a different way to achieve the same result as solution 
  139.   #1. However they are more advanced and may require the assistance of a skilled 
  140.   Oracle administrator
  141.   
  142.   
  143.   Solution 2:
  144.        Change the location of the archived files to be relative to the
  145.        RDBMS70 variable.  This would mean they would be located in
  146.        \ORANW\RDBMS70\ARCHIVE instead of \ORACLE\TRACE\ARCHIVE.  This 
  147.        means changing the INIT.ORA line to:
  148.   
  149.        log_archive_dest = %RDBMS70%\archive\  #
  150.   
  151.   Solution 3: (temporary solution that can be implemented w/out closing the db)
  152.        Change the archived redo log destination parameter dynamically
  153.        without having to shut down the database.  To do this issue:
  154.    
  155.        ALTER SYSTEM ARCHIVE LOG START TO 'SYS:\ORACLE\TRACE\ARCHIVE\';
  156.        Note: the single quotes around the destination path are required.
  157.   
  158.        This does not change where the archived log files are stored. 
  159.        It only changes how Oracle stores the destination path internally.  
  160.        Therefore, solution #1 should also be implemented for a 
  161.        permanent change
  162.  
  163.   
  164.   All three of the solutions above show how Oracle can point to the path of 
  165.   the archived log files without a user defined variable. Solution #1 is 
  166.  
  167.  
  168. 5. Where to locate updates mentioned in this tech note.
  169. =============================================================================
  170.   The following files mentioned in this tech note can be downloaded from 
  171.   our BBS ( 708-505-3336).
  172.   
  173.        FILENAME         PASSWORD
  174.        --------------   --------
  175.        LIBUP4.EXE       none
  176.        STRTL3.EXE       none
  177.        TSA0694.ZIP      none
  178.        LANDR3.ZIP       none
  179.        ORACL-UP.ZIP     AMOCO 
  180.        PALASDUMP.ZIP    none
  181.        PK204G.EXE       none
  182.  
  183.  
  184. 6. Information to gather before calling for support
  185. =============================================================================
  186.   To assist in solving your problem please gather the following 
  187.   information prior to calling for technical support. Providing it in 
  188.   advance will save time in getting the issue resolved. These files can be 
  189.   placed in one ZIP file & uploaded to the Palindrome BBS. If you 
  190.   decide to upload a file to our BBS you need to let the support engineer 
  191.   you are working with know the file name. If you are having trouble with 
  192.   PKZIP  type  " PKZIP /? " for help.
  193.  
  194.   Files
  195.   =====
  196.   PALSDUMP.DAT    For installation server & Oracle server
  197.           these may be the same
  198.   
  199.   INIT.ORA        Oracle configuration file
  200.   
  201.   CONFIG.ORA      Oracle configuration file
  202.   
  203.   ALERT.LOG       Oracle error log
  204.   
  205.   PNA_LOG         Palindrome error log
  206.   
  207.   Also include a text file if possible including what output is on 
  208.   the Oracle server console.
  209.  
  210.  
  211. 7. Issues with specific versions of Oracle
  212. =============================================================================
  213.   7.0.15.5 had a problem in referring to the location of the archived log 
  214.   files. The only workaround was to use a user defined variable. That is  
  215.   where we have a problem.
  216.   
  217.   7.0.15.5.2 was a specific patch to fix that problem & allow the location 
  218.   of the archived log files to be specified by a absolute path or system 
  219.   defined variable.
  220.   
  221.   7.0.16.6.0 had severe problems in memory usage & should not be used    
  222.   
  223.   7.0.16.6.5 is the latest production 7.0x release which Oracle 
  224.   want's 7.0x customers to update to.  ( as of 3-16-95 )
  225.   
  226.   7.1.3 is the latest Oracle release, however we do not 
  227.   support backing it up since it allows multiple instances of a 
  228.   database.
  229.   
  230.   As long as Oracle is 7.0.15.5.2 or later, we will not have 
  231.   trouble locating the location of the Archive Log Files.
  232.   
  233.  
  234.     
  235.  
  236.         
  237.  
  238.  
  239.