Versions Compared

Old Version 8

changes.mady.by.user richard.nahm

Saved on

compared with

New Version Current

changes.mady.by.user richard.nahm

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Patching means minor version changes.
    Altibase server version consists of 4 or 5 digits.
    The first three digits refer to the major version and the last one or two digits refer to the minor version.
    Changing the last three digits without changing the first three digits is called a 'patch', and changing the first three digits is called 'upgrade'.

  • This page describes the procedure for patching Altibase servers in Unix and Linux environments.
  • Since the Altibase server patch must be performed after the Altibase server is shut down, service downtime is required.
  • Therefore, the user must secure downtime before patching.

...

Preparation before patching

...

Check the following before proceeding.

  • Can Altibase server downtime be secured? (Confirmed with the client)
  • Does the meta version change after patching? (Confirm with Altibase engineer)
  • Are there any caveats if the patch version is different from the current version? (Confirm with Altibase engineer)
    Example: If need In order to patch from HDB 4.3.9.44 to Altibase HDB 4.3.9.233.

Patch Procedure

 

...

1. Check the current version

 

...

  • Make a note of the version check result below.

    Code Block
    titleHow to check Altibase server version
    languagebash
    $ altibase -v

...

  • Shutdown the Altibase server.

    Code Block
    titleHow to shutdown Altibase server
    languagebash
    $ server stop

    After the shutdown, check the Altibase server process and service port LISTEN status. When the following two commands are executed, there should be no results to indicate a normal shutdown.

    Code Block
    languagebash
    $ ps -ef | grep 'altibase -p' | grep -v grep           # To check the Altibase server process
$ netstat -an | grep 20300                             # To check the service port

3. Backup existing installation files
Anchor
3rdstepforpatch
3rdstepforpatch

...

  • Back up necessary directories so that problems can be recovered after patching.

    Code Block
    titleExample of directory backup
    languagebash
    $ cd $ALTIBASE_HOME
$ cp -Rp bin bin.bak
$ cp -Rp lib lib.bak
$ cp -Rp msg msg.bak
$ cp -Rp conf conf.bak
$ cp -Rp include include.bak

    If the size of the $ALTIBASE_HOME directory is not large, the user can make a full backup of the $ALTIBASE_HOME directory as shown below.

    Code Block
    $ cp -Rp altibase_home altibase_home.bak

...

  • Log in as the ALTIBASE HDB server installation user.
  • Upload the patch package to a random path.
  • From ALTIBASE HDB server version 5.5.1, the Java-based installer was used, and the package name ends with .run as shown below.

  • Grant execute permission to run the package.

    Code Block
    titleHow to change execution permission
    languagebash
    $ chmod +x altibase-HDB-server-6.1.1.3.8-LINUX-X86-64bit-release.run

...

  • If the default password (manager) of the sys user is changed, the $ATLIBASE_HOME/bin/server, is, il scripts would have changed.

  • In this case, copy server, is, and il from the bin directory of the backup directory to $ALTIBASE_HOME/bin.

    No Format
    $ cd $ALTIBASE_HOME
$ cp -p bin.bak/server bin/
$ cp -p bin.bak/is bin/
$ cp -p bin.bak/il bin/

8. STARTUP ALTIBASE HDB Server **
Anchor
8thstepforpatch
8thstepforpatch

...

  • If the meta version changes, the database cannot be reverted to a lower version.
  • After patching to a higher version, there may be cases where the user inevitably needs to revert to a lower version. If the meta version is changed, this cannot be done.
  • Therefore, if the meta version changes, the user should be aware of this and proceed with the patching, and if necessary, take an offline full backup before the patch.
  • Offline full backup targets include data files, log anchor files, log files, and configuration files.

...

  1. Secure the Altibase server downtime

  2. Shutdown the Altibase server (Refer to step 2 of the patch procedure)

  3. Change the service port
    Temporarily change the service port during patching to ensure that access to Altibase is blocked.

    Code Block
    languagebash
    $ cd $ALTIBASE_HOME/conf 
$ vi altibase.properties               # Changed PORT_NO in altibase.properties.
  4. Startup the Altibase server (Refer to step 3 of the patch procedure)

  5. Check the replication gap**
    Must make sure it is 0.

    Code Block
    titleHow to check replication cap
    languagesql
    iSQL> SELECT REP_GAP FROM V$REPGAP;

  6. Backup the replicated object creation syntax by performing aexport

    Code Block
    $ aexport                      # The user can check the syntax for creating a replication object in the SYS_CRT_REP.sql file created after performing aexport.

  7. Drop replication object**

    Code Block
    -- Check the replication object name
iSQL> SELECT REPLICATION_NAME FROM SYSTEM_.SYS_REPLICATIONS_;

-- Stop the replicaiton
iSQL> ALTER REPLICATION replication_name STOP;

-- Drop replication object
iSQL> DROP REPLICATION replication_name;

  8. Perform the checkpoint

    Code Block
    languagesql
    iSQL> ALTER SYSTEM CHECKPOINT;                   -- Repeat 4 times
  9. Shutdown the Altibase server (Refer to step 2 of the patch procedure)

  10. Perform the patch (Refer to step 2 to step 7 of the patch procedure)

  11. Add CHECK_LOGFILE property**

    Code Block
    languagebash
    $ cd $ALTIBASE_HOME/conf 
$ vi altibase.properties               # Save after adding CHECK_LOGFILE = 0 to the last line of altibase.properties file.
  12. Startup the Altibase Server (Refer to step 8 of the patch procedure)

  13. Delete CHECK_LOGFILE property**

    Code Block
    languagebash
    $ cd $ALTIBASE_HOME/conf 
$ vi altibase.properties               # CHECK_LOGFILE added to the last line of altibase.properties file = 0 Delete and save.

  14. Insert data after creating temporary table
    This is to use up the log files created in the previous version and create a new log file.

    No Format
    CREATE TABLE IMSI_T (C1 INTEGER, C2 INTEGER);

CREATE OR REPLACE PROCEDURE IMSI_PROC AS V1 INTEGER;
BEGIN
FOR V1 IN 1 .. 300000 LOOP
INSERT INTO IMSI_T VALUES (V1, V1);
END LOOP;
END;
/
    Code Block
    languagesql
    iSQL> SELECT CUR_WRITE_LF_NO FROM V$LFG; - Check the result (number).
iSQL> EXEC IMSI_PROC; - Perform an insert on a temporary table.
iSQL> SELECT CUR_WRITE_LF_NO FROM V$LFG; - If it is greater than the result checked above, it is completed. If it is not different from the result checked above, re-execute the IMSI_PROC procedure.
iSQL> DROP PROCEDURE IMSI_PROC; - Drop temporary tables and procedures.
iSQL> DROP TABLE IMSI_T;

  15. Perform the checkpoint

    Code Block
    languagesql
    iSQL> ALTER SYSTEM CHECKPOINT;                   -- Repeat 4 times.

  16. Create replication object

    Code Block
    $ is -f SYS_CRT_REP.sql                          # Execute the created SYS_CRT_REP.sql file after executing aexport.

  17. Start replication

    Code Block
    languagesql
    - Check the replicaiton object name
iSQL> SELECT REPLICATION_NAME FROM SYSTEM_.SYS_REPLICATIONS_;
- Stop the replication
iSQL> ALTER REPLICATION replication_name START;

  18. Shutdown Altibase server (Refer to step 2 of the patch procedure)
    Change the temporarily changed service port to the original.

     

  19. Change the service port
    Change the temporarily changed service port to the original.

    Code Block
    $ cd $ALTIBASE_HOME/conf 
$ vi altibase.properties               # Changed PORT_NO in altibase.properties.
  20. Startup the Altibase server (Refer to step 8 of the patch procedure)

  21. Check the service