State based description of activity when performing a schema change in Advance Availability
search cancel

State based description of activity when performing a schema change in Advance Availability

book

Article ID: 281450

calendar_today

Updated On:

Products

CA Service Management - Service Desk Manager CA Service Desk Manager

Issue/Introduction

The following article describes the state of a given AA environment during the action to publish a schema change.  

Throughout the course of applying a schema change, one may be interested to know the state of each server at a given point in the process.

This article defines the servers by name as "BG01", "SB01", and "App01".  It is important to understand that a given server's state as a "background", "standby" or "Application" Server is NOT defined by the name of the server, but the result of running "pdm_server_control -t" on the given server.

At the end of each step, a review of the servers' state is given, where the server's status is given; is services up or down, identification of the server type through "pdm_server_control -t" command, and if any schema changes are present.

The scenario takes place in the above environment without any schema changes of any kind previously introduced, and the schema change to be introduced will be a table called "ztesttable1".

To test if a given server has received schema updates, one will need to do the following:

  • Search all of the given server's NX_ROOT\site\mods for the presence of any file that contains "wsp" in the file name.  This includes:
    • wsp.altercol (present on server that will experience "pdm_publish" and only before execution of same)
    • wsp.altertbl (present on server that will experience "pdm_publish" and only before execution of same)
    • wsp.mods (present on server after it has directly experienced "pdm_publish")
    • wsp_index.sch (present on server after it has directly experienced "pdm_publish")
    • wsp_schema.log (present on server after it has directly experienced "pdm_publish")
    • wsp_schema.sch (present on server after it has directly experienced "pdm_publish")
    • wsp.mods.pub (present on server that will be receiving schema updates, and did not experience "pdm_publish" directly)

  • Examine the above wsp files and the file "ddict.sch" for the existence of the given table "ztesttable1".  One can leverage a text editor on these files to verify the presence of this table.

  • Execuction of the command "pdm_extract ztesttable1".  This command will fail if the backend schema does not contain a valid defintion of the ztesttable1.

Resolution

Step 1.  Initial state:

State Check:

  • Output of commands:  pdm_server_control -t and pdm_status
    BG01:  Background (Services running)
    SB01:  Standby (Services running)
    App01: Application (Services running)

  • Status of Schema changes
    BG01:  No signs of schema update
    SB01:  No signs of schema update
    App01: No signs of schema update

Step 2:  Perform Schema Changes

a.  BG01:  make schema changes in Schema Designer (created table ztesttable1), save, publish
b.  BG01:  Stop SDM Services 
c.  BG01:  run pdm_server_control -b

State Check after above is completed (assuming no errors): 

  • Output of commands:  pdm_server_control -t and pdm_status
    BG01:  Standby (Services NOT running)
    SB01:  Background (Services running)
    App01: Application (Services running)

  • Status of Schema changes
    BG01:  Schema updates detected and ready to be published (found wsp.altercol and wsp.altertbl in site/mods)
    SB01:  No signs of schema update
    App01: No signs of schema update

Step 3:  Publish Schema Changes

a.  BG01:  run pdm_publish
b.  BG01:  Will be prompted "Do you want pdm_publish to start CA Service Desk Manager in this standby server and perform fail-over(Y/N)?".  Say "Y"

State Check after above is completed (assuming no errors): 

  • Output of commands:  pdm_server_control -t and pdm_status
    BG01:  Background (Services running)
    SB01:  Standby (Services NOT running)
    App01: Application (Services running)

  • Status of Schema changes
    BG01:  Schema updates detected.  files wsp_index.sch, wsp_schema.log, wsp_schema.sch, and wsp.mods detected, ddict.sch shows new table, "pdm_extract ztesttable1" is accessible.
    SB01:  No signs of schema update
    App01: No signs of schema update

Step 4:  Propagate Schema Changes out to SB01

a.  SB01:  Services already stopped, start Services back up.

State Check after above is completed (assuming no errors): 

  • Output of commands:  pdm_server_control -t and pdm_status
    BG01:  Background (Services running)
    SB01:  Standby (Services running)
    App01: Application (Services running)

  • Status of Schema changes
    BG01:  Schema updates detected (per Step 3)
    SB01:  Schema updates detected (file wsp.mods.pub detected, ddict.sch shows new table, "pdm_extract ztesttable1" is accessible)
    App01: No signs of schema update

Step 5:  Propagate Schema Changes out to App01

a.  App01:  Restart services.  Stop, then start Services.

State Check after above is completed (assuming no errors): 

  • Output of commands:  pdm_server_control -t and pdm_status
    BG01:  Background (Services running)
    SB01:  Standby (Services running)
    App01: Application (Services running)

  • Status of Schema changes
    BG01:  Schema updates detected (per Step 3)
    SB01:  Schema updates detected (per Step 4)
    App01: Schema updates detected (file wsp.mods.pub detected, ddict.sch shows new table, "pdm_extract ztesttable1" is accessible)

Additional Information

The key action when performing a schema update is to always use the SAME server to run Schema Designer and run "pdm_publish".  This is because the given activity will read the wsp_schema.log file on the local server to keep track of schema changes.  In the above, one will need to always start out schema changes on server BG01 to run Schema Designer and pdm_publish.

Powered by Wolken Software