Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2006-04-26 10:18:57
Size: 475
Editor: lalinekw2
Comment:
Revision 18 as of 2006-06-21 07:45:29
Size: 5458
Editor: lalinekw2
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== DBIDs for PACS Databases == = PACS Databases =
Line 5: Line 5:
* 12000 - 12250 : public databases for operations <br>
* 12001 : pacseqmimt1e
* 12002 : cusdefinitions (warm tests of cus scripts : 20060426

* 12251 - 12699 : additional datbases
 * 12000 - 12250 : public databases for operations <br>
   * 12001 : pacseqmimt1e : database copy from Astrium EQM tests end 2005 - serious problems with schema evolutions etc.
   * 12004 : sftcode : public CUS development database - schema 24
   * 12006 : aotcode : AOT reference database 20060426 / for warm AOT tests - schema 24
   * 12003 : leuven : schema 24
   * 12007 : aottest2 : Database for End2End Test incl. Pointing files. filled by Diego / running also for Roland tests / schema 23
   * 12008 : aottest3 : Copy of aottest2 for tests @MPE - schema24


 * 12251 - 12699 : additional datbases
Line 13: Line 18:
* 12700 - 13000 : public databases for operations
* 13001 - 13399 : additional datbases
 * 12700 - 13000 : public databases for operations
 * 13001 - 13399 : additional datbases
Line 17: Line 22:
* 13400 : EQMILT1@Astrium  * 13400 : EQMILT1@Astrium
Line 20: Line 25:



= Seting the Database IDs =
I have the feeling that a given DB ID cannot be re-used also if the database has been removed.
Need clarification...

{{{
dbid -r cusdefinitions -> show DBID
dbid -d cusdefinitions -> delete DBID
setdbid 12002 cusdefinitions -> set DBID
dbid -C 12002 cusdefinitions
}}}



= Updating Database Engine =

 * Log in as dbsa on PACS1.

 * Check Database engine :
   {{{
     oscp -i
     oscp -l
   }}}

 * Download the new Database engine version from ESA page :
   ftp://ftp.rssd.esa.int/pub/HERSCHEL/csdt/temp/

   teamCSDT : usecases

 * Save license file of previous version
   {{{
      cp /usr/local/versant/<versant-previous>/license.xml ~
   }}}

 * Sometimes you may request new license file (license.xml) from tzaeschk@rssd.esa.int

 * Log in as root on PACS1.
 * Check disk space /usr/local is quite full already.
   {{{
     df -h
   }}}

 * Change to /usr/local/versant and make a directory to copy and extract the tar file.
   {{{
     cd /usr/local/versant
     mkdir 7.0.1.1
     cd 7.0.1.1
     tar -zxvf vod7011_rhel.tar
     ./install.bin
   }}}

 * Just to be sure check again the system setup and restart the xinetd :
   {{{
     oscp -i
     oscp -l
     /etc/rc.d/xinetd restart
   }}}

 * Install license file of previous version or requested one
   {{{
      cp license.xml /usr/local/versant/<versant-previous>
   }}}

 * Modify psetup scipt on PACS1 : account pcss
   {{{
      emacs /home2/pcss/psetup
   }}}
   For example :
   {{{
    # Can use /etc/.osc... instead of these 4 variables
    setenv VERSANT_ROOT /usr/local/versant/7.0.1
    setenv VERSANT_DB /dbOper/versant
    setenv VERSANT_DBID /dbOper/versant
    setenv VERSANT_DBID_NODE pacs1

    set path=( /usr/local/versant/7.0.1/bin $path )
    set LIB_DIR=/usr/local/versant/7.0.1/lib

    setenv LD_LIBRARY_PATH /usr/local/versant/7.0.1/lib:${LD_LIBRARY_PATH}

    setenv THREADS_FLAG native
   }}}



= Schema evolution =

 * Download and install PCSS containing the new Schema.

 * Check LD_LIBRARY_PATH (need to point into newest database engine directory

   non proper settings can lead to unfinished evolution which destroy the database !!

   e.g. /usr/local/versant/7.0.1
   {{{
     setenv LD_LIBRARY_PATH /usr/local/versant/7.0.1/lib
   }}}
 
  !!! The PCSS libjvi7.0.1.so caused problems in the past. You should set it to the proper VERSANT one ONLY !!!

 * Check whether actualVersant engine match the reference platform engine : ftp://ftp.rssd.esa.int/pub/HERSCHEL/csdt/releases/doc/refPlatformVersion
   {{{
       oscp -l
   }}}

 * Send out Schema evolution warning.

 * Make sure that Databases are not used :
   {{{
     dbtool -trans -info <DBName>
   }}}

 * Make a backup of the database :
   {{{
     vbackup -dev <DBName>.vbck -backup <DBName>
   }}}

 * Set Databases to single user mode :
   {{{
     dbinfo -1 <DBName>
   }}}

 * Perform schema evolution as described in the Database Administration Manual (HSCDT/TN044) :
   {{{
     schema_evolver <DBName>
   }}}

 * Set the Database back to multi user mode :
   {{{
     dbinfo -m <DBName>
   }}}

 * Test from an arbitrary account
    * set in .pcss/props the Database to the schema evolved one
    * start cusgui

 * Send message to user.


= Traps and Tricks =
== Replication aware Datbase or not ==
Sometimes you get an error that the Database is Replication aware or not and does not match to your access

You have two options :
 * set the property :
   {{{
      hcss.store.factory = herschel.versant.store.ReplStoreFactoryImpl
   }}}

 * Remove the replication mechansim from the Database :
   {{{
      db_admin -u <DBName>
   }}}

== Hot Spot error for remote access ==
When a remote user (like Diego) start cusgui and he/she gets a java hotspot whaever error it might be caused by the user access rights !

A strange error for such a problem. Locally access you get a proper error message.

Do :
{{{
  dbuser -add -P <DBName>
}}}

== Check whether there are open transactions ==
{{{
   dbtool -trans -info <DBName>
}}}

= Delivery of Databases to ESAC =
Make a backup of the Database :
{{{
   vbackup -dev <name>_<version>.vbck -backup <name>
}}}

and put the backup on PACS1 /home/esac/databases

send an email to
John Dowson <John.Dowson@sciops.esa.int>
Larry O'Rourke <Laurence.O'Rourke@esa.int>

PACS Databases

a. Databases @ MPE 12000 - 12699

  • 12000 - 12250 : public databases for operations <br>

    • 12001 : pacseqmimt1e : database copy from Astrium EQM tests end 2005 - serious problems with schema evolutions etc.
    • 12004 : sftcode : public CUS development database - schema 24
    • 12006 : aotcode : AOT reference database 20060426 / for warm AOT tests - schema 24
    • 12003 : leuven : schema 24
    • 12007 : aottest2 : Database for End2End Test incl. Pointing files. filled by Diego / running also for Roland tests / schema 23

    • 12008 : aottest3 : Copy of aottest2 for tests @MPE - schema24
  • 12251 - 12699 : additional datbases

b. Databases @KUL 12700 - 13399

  • 12700 - 13000 : public databases for operations
  • 13001 - 13399 : additional datbases

c. Other databases 13400 - 13500

  • 13400 : EQMILT1@Astrium

d. Spare 13500 - 13999

Seting the Database IDs

I have the feeling that a given DB ID cannot be re-used also if the database has been removed. Need clarification...

dbid -r cusdefinitions -> show DBID
dbid -d cusdefinitions -> delete DBID
setdbid 12002 cusdefinitions -> set DBID
dbid -C 12002 cusdefinitions 

Updating Database Engine

  • Log in as dbsa on PACS1.
  • Check Database engine :
    •      oscp -i 
           oscp -l
  • Download the new Database engine version from ESA page :
  • Save license file of previous version
    •       cp  /usr/local/versant/<versant-previous>/license.xml ~
  • Sometimes you may request new license file (license.xml) from tzaeschk@rssd.esa.int

  • Log in as root on PACS1.
  • Check disk space /usr/local is quite full already.
    •      df -h
  • Change to /usr/local/versant and make a directory to copy and extract the tar file.
    •      cd /usr/local/versant
           mkdir 7.0.1.1
           cd 7.0.1.1
           tar -zxvf vod7011_rhel.tar
           ./install.bin
  • Just to be sure check again the system setup and restart the xinetd :
    •      oscp -i
           oscp -l
           /etc/rc.d/xinetd restart
  • Install license file of previous version or requested one
    •       cp  license.xml /usr/local/versant/<versant-previous> 
  • Modify psetup scipt on PACS1 : account pcss
    •       emacs /home2/pcss/psetup
      For example :
          # Can use /etc/.osc... instead of these 4 variables
          setenv VERSANT_ROOT      /usr/local/versant/7.0.1
          setenv VERSANT_DB        /dbOper/versant
          setenv VERSANT_DBID      /dbOper/versant
          setenv VERSANT_DBID_NODE pacs1 
      
          set path=( /usr/local/versant/7.0.1/bin $path )
          set LIB_DIR=/usr/local/versant/7.0.1/lib
      
          setenv LD_LIBRARY_PATH /usr/local/versant/7.0.1/lib:${LD_LIBRARY_PATH}
      
          setenv THREADS_FLAG native

Schema evolution

  • Download and install PCSS containing the new Schema.
  • Check LD_LIBRARY_PATH (need to point into newest database engine directory
    • non proper settings can lead to unfinished evolution which destroy the database !! e.g. /usr/local/versant/7.0.1
           setenv LD_LIBRARY_PATH /usr/local/versant/7.0.1/lib  
    • !!! The PCSS libjvi7.0.1.so caused problems in the past. You should set it to the proper VERSANT one ONLY !!!
  • Check whether actualVersant engine match the reference platform engine : ftp://ftp.rssd.esa.int/pub/HERSCHEL/csdt/releases/doc/refPlatformVersion

    •        oscp -l
  • Send out Schema evolution warning.
  • Make sure that Databases are not used :
    •      dbtool -trans -info <DBName>
  • Make a backup of the database :
    •      vbackup -dev <DBName>.vbck -backup <DBName>
  • Set Databases to single user mode :
    •      dbinfo -1 <DBName>
  • Perform schema evolution as described in the Database Administration Manual (HSCDT/TN044) :
    •      schema_evolver <DBName>
  • Set the Database back to multi user mode :
    •      dbinfo -m <DBName>
  • Test from an arbitrary account
    • set in .pcss/props the Database to the schema evolved one
    • start cusgui
  • Send message to user.

Traps and Tricks

Replication aware Datbase or not

Sometimes you get an error that the Database is Replication aware or not and does not match to your access

You have two options :

  • set the property :
    •       hcss.store.factory = herschel.versant.store.ReplStoreFactoryImpl
  • Remove the replication mechansim from the Database :
    •       db_admin -u <DBName>

Hot Spot error for remote access

When a remote user (like Diego) start cusgui and he/she gets a java hotspot whaever error it might be caused by the user access rights !

A strange error for such a problem. Locally access you get a proper error message.

Do :

  dbuser -add -P <DBName>

Check whether there are open transactions

   dbtool -trans -info <DBName>

Delivery of Databases to ESAC

Make a backup of the Database :

   vbackup -dev <name>_<version>.vbck -backup <name>

and put the backup on PACS1 /home/esac/databases

send an email to John Dowson <John.Dowson@sciops.esa.int> Larry O'Rourke <Laurence.O'Rourke@esa.int>

Herschel: PACS/Database (last edited 2009-07-15 14:32:38 by localhost)