The risks and the devastating effects of disasters resulting in computer downtime are obvious and always pose a pressing issue to any business running critical applications. Business organizations demand 100% fault tolerance and continuous availability of their computing systems. Relying on traditional, full system backups means that any critical data and transactions executed after the last system backup are lost forever. The use of traditional backups also means that data at the remote site always lags behind, so that the remote computers can not be used for online production processing and can only be utilized in course of a disaster-recovery scenario. For this reason, these vital and expensive resources are idle while the primary computer, in many cases, is over-loaded and suffering from deteriorated performance.

DRMS is a software solution that provides reliable, bi-directional real-time data backup and mirroring over existing Stratus networks. At any given time, all critical remote databases are identical to the primary database, which ensures rapid and reliable application recovery. Networked computers mirror each other providing flexible, scaleable load-balancing solution utilizing the full computing capacity of the hardware at both the primary and remote locations. DRMS replicates sequential, fixed, relative and stream files (including transaction-protected files) as well as, one-way-server-queue and message queues. DRMS dynamically detects and replicates newly created critical files so that no configuration changes are necessary. The internal design of DRMS puts great emphasis on protecting the business application and on preserving the primary computer's current performance. DRMS is external to the business application and requires absolutely no application or any software changes - its operation is completely transparent to the user.

There are other considerations and reasons for mirroring critical databases:

• Provide rapid & reliable data replication of mission critical applications to any file system on any platform, such as Stratus VOS, MS ACCESS, MS SQL, ORACLE, DB2, INFORMIX SYBASE etc.

• Ease development of browser based (GUI) applications.

• Access Stratus Data from more common development environment (NT, UNIX etc.)

• Shift CPU intensive report writing, decision support systems and date warehouse applications away from Stratus to more economical (and less critical) environment.

• Develop or extend your IT strategy to enable gradual and parallel development of alternate solutions

organization:		   relative; 
fields      :
record_type		   char (32) var,
run_on_module                 char (66) var,
priority                      bin (15) default ('8'),
tcp_host                      char (32) var,
tcp_port                      bin (15),
max_buffer_len                bin (15) default ('8196'),
primary_call_timeout          bin (15) default ('60'),
max_file_errors               bin (15) default ('50'),
log_statistics_on_close       bit (1)  default ('1'),
tp_abort_timeout              bin (15) default ('2'), 
substitute_system_name        char (32) var,
appl_show_stats               bit  (1),
appl_mirror_default_output    bit  (1),
appl_send_alerts_to_25th_line bit (1) default ('1'),
appl_send_alrets_to_syserr_log bit (1) default ('1'),
check_file_at_open            bit (1) default ('1'),
check_file_at_close           bit (1) default ('1'),
check_file_interval           bin (15),
use_tp                        bit (1)  default ('1'),
appl_q_timeout                bin (31) default ('2'),
primary_max_buffers           bin (15) default ('1000'),
appl_max_buffers              bin (15) default ('200'),
primary_q_read_timeout        bin (15) default ('120'),
user_application_q_timeout    bin (15) default ('5'),
use_yield_processor           bit (1)  default ('0'),
sort_buffer                   bin (15) default (30),
no_of_queues                  bin (15) default (1),
replace_special_chars         bit (1) default (1),
qmon_warn_at                  bit (15),
disable_drms		  bit default ('1'),
resume_at_q_depth	  	  bin (15) default ('10000'),
keep_trying		  bit default ('1'),
trace_level                   bin (15);
end;

Field Definitions

/=record_type       include
 =process_name      *
 =source_path       %prim#d03>PROD>data>my_critical_file

The DRMS Files Table (drms_files.table)

Programs that access critical files in a read-only mode do NOT require any mirroring and should be excluded from this activity.

organization:  	relative;
fields      :
record_type         char (32) var  default ('include'),
process_name        char (32)  var,       
source_path         char (256) var,
destination_dir     char (256) var,
drms_server	  bin (15),
in_any_directory    bit 1,
auto_synchronize     bit (1)
dont_send_reads      bit (1)
extractor_file_id   bin (15),
equalize_interval   char (32) var,
equalize_if_new     bit (1),
equalize_if_modified bit (1),
equalize_if_locked   bit (1),
report_orphans       bit (1),
delete_orphans       bit (1),
end;                                                            

Field Definitions

/=record_type    	include
=process_name   	*
=source_path 	[production-dir>MainTxnFile
=mirroring_dir  	[hot-backup-directory]

/=record_type    	include
=process_name   	TradeProcessor*
=source_path 	[production-dir]>MainTxnFile
=mirroring_dir  	[hot-backup-directory]

/=record_type    	exclude
=process_name   	ReportTxn
=source_path 	[production-dir]>MainTxnFile
=mirroring_dir  	[hot-backup-directory]

/=record_type    exclude
=process_name   *
=source_path    [production-dir]>LogFile

/=record_type    exclude
=source_path    *.kp

recover_servers Starts all DRMS servers as defined in the drms.table file while recovering all active ports recorded in the Checkpoint file.

Click to enlarge:

Purpose

CRT Form

---------------------------------- DRMS Sync.  --------------------------------
 files:  
 -index 
 

Lineal Form

drms_sync.pm  [files] -index [index-name]

Arguments

Any valid unique-indexed data file which is defined as a critical file within the drms_file.tin configuration. You can also use a star-name.

-index

Use this option only if the file is encrypted using the Encryptor software to specify the name of a non-duplicates index name.

You should be able to complete this basic test within a few minutes.

1. Start the Servers
2. Execute the program: drms_demo.pm
3. The program should produce a test_file in the current directory and a mirror image of the file in the mirroring_dir directory.
4. Compare the test_file created in the DRMS directory with it's mirror image under DRMS>mirroring_dir directory.

Note that this initial test should be completed without having to change any of the configuration files.

• add_default_library_path command [SPS>DRMS]
• add_default_library_path object [SPS>DRMS]

Add your application's critical processes and files to the DRMS configuration table (drms_files.tin). Make sure that files selected for mirroring exist on the Backup module and are identical to the files on the Primary module. Use the compare_files command for this purpose. If necessary, use the copy_file or create_file commands to complete the Backup set of files.

Modify the drms.table to include your own communication configuration IP address and the port number.

You are now ready to start the DRMS servers on both modules - click on start-servers.

You'll need to wait a few seconds until all processes are started and connect to each other. You should expect a message on you terminal's 25th line announcing that a connection was established.

Once connected, you'll be ready to start your application processes.

drms_*.q: A queue used for inter-process communications between the user's application and the DRMS software.

drms.vm: Virtual Memory used by the DRMS server to keep and report statistics.

[user-application-process-name].drms: A log file used by the user's application to report file I/O and s$ call activities as well as any errors that the application may encounter while communicating with DRMS.

Backup.(date): A log file maintained by the DRMS_Backup server.

Application.(date): A log file maintained by the DRMS_Backup_App server.

Primary.(date): A log file maintained by the DRMS_Primary server.

Application_X.q: An internal queue used on the Backup machine to support communication between the DRMS_Backup and the DRMS_Backup_App process(es). The X stands for the number of the queue being used.

drms_to_lams.q: A queue used for passing internal messages, warnings and run-time errors to SPS/Logs & Alert Manager.

   File-Extractor-ID(s) 1-99 are reserved for XML formatted outputs where IDs higher than 100 are normally used to create SQL statements and therefore require three different Templates - for INSERT, UPDATE and DELETE (template.NNN.i, template.NNN.u, template.NNN.d)

   SQL by its nature require in most cases one or more indexes. Therefore files used for SQL conversion must be opened for update in indexed mode and all operations must be perfumed by s$keyed_xxx operations. Sequential writes are updates are supported but sequential updates and deletes are not.

1. Make sure the VM file is defined as a critical file in your drms_files.table.
2. Edit the drms_sync_vm_01.bind file
3. Adjust the the modules section to match your application's bind VM regions. Be sure to specify the modules in the same order.
4. For every region, adjust:
   • the region_path_N (path-name of the file)
   • region_pages_N (number of pages to connect to)
   • region_interval_N (how often to runout, specified in seconds)
5. You may repeat the process for up to 10 VM regions.
6. Add the following entry to drms.tin:

   /=record_type                                SYNCHRONIZE_VM
    =run_on_module                              [your-production-module]
    

1. Check DRMS communications:
   • Are both DRMS processes running and properly started?
   • Run list_users and make sure there is only DRMS_Primary process running on the primary system and only DRMS_Backup and DRMS_Application are running on the backup module. If you have multiple DRMS environments, make sure only one is being used.
   • Review both systems, focus on the communication servers (DRMS_PRIMARY, DRMS_BACKUP).
   • Look for any error messages in their log files (list *.(date)).
   • In the DRMS directory, execute "who_locked *pm" and verify that the drms.pm is being locked.

2. Run the test program - drms_demo.pm:
   • Delete the DRMS>mirroring_dir>test_file on the Backup side.
   • Run the drms_demo.pm program.
   • Verify that the test_file has properly mirrored to the Backup directory.
   • Look for any errors.
   • Review the DRMS_Application log on the Backup module, look for any errors.
   • Review the monitor screen, make sure that counters are changing as expected.

3. Check the application programs:
   • Is your application bound with the drms_routines.obj objects?
   • Does the application name in the configuration table match (exactly!) the name of your process (background) or program name (foreground)?
   • Does the =source_path configuration path match the path name of the file you are mirroring?
   • Verify that the your application is not excluded within the drms_files.table configuration.
   • Verify that the DRMS directory appears in the module's default library paths - both command and object lists. Use the list_default_library_paths command.
   • On the primary module, log into the system using the same user-id that under which the application is running and execute 'where_command drms.pm;list_library_paths' review the output-file.
   • On the backup module, review the DRMS_Application log file; look for errors or traces for connection attempts from the application program in question.
   • Review the queue-monitor screen to verify that messages are being transferred and delivered.
   • On the Primary module, set sufficient access right (modify/write) to allow the application to create and write its log files in the SPS>DRMS>logs subdirectory.

Important Operation considerations

If you make configuration changes, it is not required to start and restart the DRMS servers - ONLY THE APPLICATION must be restarted.

DRMS must be up and running BEFORE THE APPLICATION IS STARTED.

If DRMS (primary) is started before the backup side, it may take up to one minute for them to connect.

Under no (normal) circumstances should you stop ANY DRMS server(s).