Smart Grid Infrastructure: Oracle &

DBVisit As-Built

Page | 1
Document Change History

Document control sheet

If you have any questions regarding this document or a suggestion for improvements, please contact:

Document Owner DIVANSHU CHOPRA Phone +61 406914380

Document Authorization
Name/Title Signature Date
Prepared by: Divanshu Chopra 16th February 2015
Modified by:
Jaivardhan Singh
Reviewed by: 4th January 2018
Bairaria
Accepted by:

Version History
Version Author Issue Purpose Date
0.1 Raymond Allo Initial Draft 20/08/2013
0.2 Hong Tran Reviewed and 19/09/2013
formatted
1.0 Raymond Allo Updated with 7/10/2013
customer feedback
2.0 Hong Tran Released 7/10/2013
2.3 Raymond Allo Added DBVisit and 16/10/2013
RMAN sections
3.0 Hong Tran Released 18/10/2013
3.1 Divanshu Chopra Added Standby Sync 05/12/2016
Procedure through DB
Visit
3.2 Jaivardhan Singh Reviewed ,no updates 04/01/2018
Bairaria required

The following people can be contacted in relation to this document:

Title Name Telephone Email
Taranjit Singh TaranjitSin.Boonga@endeavourenergy.com.au
DBA +919910068809
Boonga
Jaivardhan JaivardhanS.Bairaria@endeavourenergy.com.au
DBA +918742831841
Singh Bairaria

Peer Reviewers
Title Name Date Review Outcome
DBA Taranjit Singh Boonga 31st July 2017 Reviewed
Reviewed, no
DBA Jaivardhan Singh Bairaria 4th January 2018
updates required.

Page | 2
Glossary
S.No Abbreviation Description
1 SMTP Simple Mail Transfer Protocol
2 DNS Domain Naming System
3 DC Domain Controller
4 SQL Structured Query Language
5 MS-SQL Microsoft SQL Server
6 RDBMS Relational Database Management System
7 BKUP Back Up (or Backup)
8 FSD File System Device
9 VM Virtual Machine
10 VCB VMware Consolidated Backup
11 SAN Storage Area Network
12 WAN Wide Area Network
13 LAN Local Area Network
14 NIC Network Interface Card
15 RPO Recovery Point Objective
16 RTO Recovery Time Objective
17 VM Virtual Machine
18 VC/VCS VMware vCenter Server
19 vSwitch VMware Virtual Switch
20 ESXi VMware ESXi Server
21 NIC Network Interface Card

Page | 3
Table of Contents
SMART GRID INFRASTRUCTURE: ORACLE & DBVISIT AS-BUILT ............................................................................. 1
1 INTRODUCTION .............................................................................................................................. 5
1.1 Overview......................................................................................................................... 5
1.2 Purposes/Requirement .................................................................................................... 5
1.3 Scope.............................................................................................................................. 5
1.4 Achievements after the Task ............................................................................................. 5
2 ORACLE CONFIGURATION ........................................................................................................... 6
2.1 Oracle Hardware Details ................................................................................................... 6
2.2 Oracle Software and Patch Level Details ............................................................................ 6
2.3 DBVisit Software and Patch Level Details ........................................................................... 6
3 ORACLE - DBVISIT CONFIGURATION ......................................................................................... 8
3.1 Database Server Setup ..................................................................................................... 8
3.2 Configured Database Instance Details ................................................................................ 8
3.3 Init<xxxx>.ora Database Instance Configuration.................................................................. 8
3.4 Username Password ...................................................................................................... 10
3.5 DBVisit configuration ..................................................................................................... 10
4 BOOT AND STANDBY MANAGEMENT ...................................................................................... 12
4.1 Boot ............................................................................................................................. 12
4.2 Oratab .......................................................................................................................... 12
4.3 Standby database management ...................................................................................... 12
4.4 Archive log management ................................................................................................ 13
5 USING DBVISIT ............................................................................................................................. 14
5.1 Resending archive logs ................................................................................................... 14
5.2 Archivelog mode switched off ......................................................................................... 14
5.3 Graceful Switchover (role reversal) .................................................................................. 15
5.4 Failover ......................................................................................................................... 17
5.5 DBVisit Housekeeping .................................................................................................... 17
6 USING DB VISIT TO SYNC STANDBY DATABASE USING INCREMENTAL BACKUP .......... 19
APPENDIX A – SCRIPTS ........................................................................................................................ 25
APPENDIX B – TECHNICAL REQUIREMENTS .................................................................................... 28

Page | 4
1 Introduction
1.1 Overview
This document contains information about Smart Grid Infrastructure in EE environment.
It presents details about hardware, software, and installation of Oracle and DBVisit in
Smart Grid Infrastructure.

1.2 Purposes/Requirement
The purpose of this document is to present the as-built documentation for the Oracle
consisting of:
• Oracle installation,
• Oracle configuration,
• DBVisit installation,
• DBVisit configuration
This will also help the DBA to work on tasks related to DB Visit like DR recovery &
restoration.

1.3 Scope
The scope of this document is limited to the Smart Grid Oracle Infrastructure and
availability architecture. The following list details items that are included in this
document;
 Oracle setup
 DBVisit setup
 Failover and failback

1.4 Achievements after the Task

Installation ,configuration and
administrative Oracle and DBVisit
Purpose in OT Infrastructure
Task Follow Steps from section II
Installation ,configuration and
administrative Oracle and DBVisit
Results in OT Infrastructure

Page | 5
2 Oracle Configuration
2.1 Oracle Hardware Details
Description Value

Number of 2
Servers

Hardware IBM HS23 Xeon 6C E5-

Model / 2640 [7875-B2M]
Type
CPU 1 x Intel Xeon E5-2640
@2.5 GHz (6-cores)
Intel VT Enabled

RAM 128GB

Network 2 x 1 Gigabit Ethernet

(Not connected)
2 x 10 Gigabit Ethernet
HBA Emulex LPe12000 8Gb
Fibre Channel Host
Adapter
USB
Memor
y Key
model
Server SGPORAA1, SGPORAB1
name
Hard Drive No Local disk

Table 1 - Oracle Hardware Details

2.2 Oracle Software and Patch Level Details

Description Value

Oracle 11.2.0.3
11R2
Oracle /opt/oracle
base
director
y
Oracle /opt/oracle/product/11.2.0/dbhome_1
home
Table 2 - Oracle Software and Patch level

2.3 DBVisit Software and Patch Level Details

Description Value

DBVisit Standby 6.0.50

Page | 6
Description Value

Installed directory /opt/dbvisit

Table 3 - DBVisit Software and Patch level

Page | 7
3 Oracle - DBVisit configuration
The following details pertain to the Oracle database instance setup for the primary
and standby database.

3.1Database Server Setup

Production and development database are spread over the A and B stack

3.2Configured Database Instance Details

Description Server

SGPRD1 sgporaa1

SGPRD2 sgporab1

SGDEV1 sgporaa1

SGDEV2 sgporab1

Table 4 – Database Instance Details

3.3Init<xxxx>.ora Database Instance Configuration

SGPRD1
*.audit_file_dest='/opt/oracle/admin/SGPRD1/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/oracle/oradata/SGPRD1/sgprd1_control01.ctl',
'/opt/oracle/fast_recovery_area/SGPRD1/sgprd1_control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='SGPRD1'
*.db_recovery_file_dest='/opt/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=SGPRD1XDB)'
*.log_archive_dest_1='LOCATION=/oracle/archive/SGPRD1'

Page | 8
*.log_archive_format='sgprd1_%t_%s_%r.dbf'
*.memory_target=4294967296
*.open_cursors=500
*.processes=550
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=610
*.undo_tablespace='UNDOTBS1'

SGPRD2
*.audit_file_dest='/opt/oracle/admin/SGPRD2/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/oracle/oradata/SGPRD2/sgprd2_control01.ctl',
'/opt/oracle/fast_recovery_area/SGPRD2/sgprd2_control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='SGPRD2'
*.db_recovery_file_dest='/opt/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=SGPRD2XDB)'
*.log_archive_dest_1='LOCATION=/oracle/archive/SGPRD2'
*.log_archive_format='sgprd2_%t_%s_%r.dbf'
*.memory_target=4294967296
*.open_cursors=500
*.processes=550
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=610
*.undo_tablespace='UNDOTBS1'

SGDEV1
*.audit_file_dest='/opt/oracle/admin/SGDEV1/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/oracle/oradata/SGDEV1/sgdev1_control01.ctl',
'/opt/oracle/fast_recovery_area/SGDEV1/sgdev1_control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='SGDEV1'
*.db_recovery_file_dest='/opt/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=SGDEV1XDB)'
*.log_archive_dest_1='LOCATION=/oracle/archive/SGDEV1'
*.log_archive_format='sgdev1_%t_%s_%r.dbf'
*.memory_target=4294967296
*.open_cursors=500
*.processes=550
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=610
*.undo_tablespace='UNDOTBS1'

SGDEV2
*.audit_file_dest='/opt/oracle/admin/SGDEV2/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/oracle/oradata/SGDEV2/sgdev2_control01.ctl',
'/opt/oracle/fast_recovery_area/SGDEV2/sgdev2_control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='SGDEV2'
*.db_recovery_file_dest='/opt/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=SGDEV2XDB)'
*.log_archive_dest_1='LOCATION=/oracle/archive/SGDEV2'
*.log_archive_format='sgDEV2_%t_%s_%r.dbf'
*.memory_target=4294967296
*.open_cursors=500
*.processes=550
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=610

Page | 9
*.undo_tablespace='UNDOTBS1'

3.4Username Password
Description Value

SGDEV1 (sys, ######

system)
SGDEV2 (sys, ######
system)
SGPRD1 (sys, ######
system)
SGPRD2 (sys, ######
system)
Table 4 - Username Password

3.5DBVisit configuration
Please note that all databases have the same configuration.
[10 Generic Settings]
ORACLE_SID = SGPRD1
ORACLE_HOME = /opt/oracle/product/11.2.0/dbhome_1
OWNER = oracle
ORATAB = /etc/oratab
CP = /usr/bin/scp
RSH = /usr/bin/ssh
COMPRESS = dbvisit
UNCOMPRESS = dbvisit
ZIP_EXTENSION = .gz
SEND_HEARTBEAT_TIME24 = 0700
TMP = /usr/tmp
PATH = /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/sbin

[15 RAC Settings]

RAC = N
RAC_TAKEOVER =
RAC_TAKEOVER_SID =
RAC_TAKEOVER_FORCE =

[20 Primary Server Settings]

SOURCE = sgporaa1
BINDIR = /opt/dbvisit/standby
ORACLE_BASE = /opt/oracle
LOGDIR = /opt/oracle/admin/SGPRD1/dbvisit
DBUSER = dbvisit
DBPASSWD = ENCRYPT53616c7465645f5f376033d21e6410f7a80e68d90f85c29b2dc4075bd7fb6e96
ENCRYPT_PASSWDS = Yes
LEAVE_COMPRESS_SOURCE = No
SYNCH_DBVISIT_INSTALL = Yes
LOGSWITCH = No
ORACLE_SID_ASM = +ASM
[25 Sys Logon Settings]
SYS_LOGON = No
SYS_USER = sys
_SYS_PASSWD =
SYS_LOGON_STRING = as sysdba
[30 Standby Server Settings]
DESTINATION = sgporab1
SSH_PORT = 22
ORACLE_SID_DEST = SGPRD1
ORACLE_HOME_DR =

Page | 10
ORACLE_BASE_DR = /opt/oracle
BINDIR_DR = /opt/dbvisit/standby
LOGDIR_DR = /opt/oracle/admin/SGPRD1/dbvisit
ARCHDEST = /oracle/archive/SGPRD1
MAX_TIMES_TRIED = 4
LEAVE_COMPRESS_DEST = Yes
ORACLE_SID_ASM_DEST = +ASM
[40 Mail Settings]
MAILCFG_MAIL_CLIENT = sendmail
SUCCESSMAIL = Yes
SUCCESSMAIL_DR = Yes
ADMINS = oracle@sgporaa1
MAILCFG_FROM = oracle@sgporaa1.com
MAILCFG_FROM_DR = oracle@sgporab1.com
MAILCFG_SMTP_SERVER =
MAILCFG_SMTP_SERVER_DR =
[50 Primary Archive Log Management Settings]
ARCHSOURCE_MANAGEMENT = No
DAYS_TO_KEEP_ARCHSOURCE =
NUM_ARCHSOURCE_TO_KEEP =
ARCHSOURCE_BACKUP_COUNT =
THRESHOLD_ARCHSOURCE =
FRA_THRESHOLD_ARCHSOURCE =
DELETE_ARCHSOURCE =
[60 Standby Archive Log Management Settings]
ARCHDEST_MANAGEMENT = Yes
DAYS_TO_KEEP_ARCHDEST = 4
NUM_ARCHDEST_TO_KEEP = 0
THRESHOLD_ARCHDEST = 80
DELETE_ARCHDEST = No
[90 Advanced Settings]
# ALL DEFAULTS

Page | 11
4 Boot and Standby management
/etc/init.d
OraStartStop: used to let dbvisit manage stopping and starting the databases in the
correct mode. Linked to
oracle : only used to stop and start the listener

Natively within the vCenter, alarm metrics can be set to alert when performance
thresholds are met and or exceeded. These alerts can be used to monitor
performance based metrics such as:
 CPU ready time
 Disk queue length
 Balloon Memory Driver Activations

4.1 Boot
At (re)boot time only the Oracle component need to be started. When DBVisit is
used the startup of the databases is managed by DBVisit instead of using the
standard Oracle startup scripts, which rely on the /etc/oratab file. Standby databases
require a special startup command set. There are two scripts in the /etc/init.d
directory:

- oracle
- OraStartStop

Both scripts are soft linked to files in the /etc/rc3.d directory

K40oracle
S20oracle
K30OraStartStop
S30OraStartStop
The oracle script file manages only the starting and stopping of the Oracle Listener.
The OraStartStop script manages the starting and stopping of the databases.

4.2 Oratab
SGPRD1:/opt/oracle/product/11.2.0/dbhome_1:N
SGDEV1:/opt/oracle/product/11.2.0/dbhome_1:N
SGPRD2:/opt/oracle/product/11.2.0/dbhome_1:N
SGDEV2:/opt/oracle/product/11.2.0/dbhome_1:N

4.3 Standby database management

The standby database synchronisation is managed by DBVisit. On the primary site
DBVisit is scheduled via a cron job. The basic operation is that every 10 minutes
DBVisit is executed and checks if any new archived redo log files needs to be
transferred DBVisit will first compress the archive log file and then transfers it to the
standby server via ssh. The archive file remains in compressed format on the standby
server.
On the standby server, DBVisit is scheduled via a cron job and will check at the set
interval if new archive logfiles have been received and need to be applied. If so,
DBVisit will uncompress the archive log file, apply it and compress it again. DBVisit
will also perform housekeeping on the archive logfiles on the standby side. The

Page | 12
 current configured retention period after applying is 4 days. After 4 days DBVisit will
delete the archive log file on the standby server side.
The current frequency is set to 10 min intervals. It is recommended to not set it
lower than 5 minutes. There is no point setting it to lower than 10 min as generally
the recommended log switch on the primary database is around 10 min.
Crontab configuration
#
# Primary database dbvisit execution
00,10,20,30,40,50 * * * * /opt/dbvisit/standby/dbvisit SGPRD1
00,10,20,30,40,50 * * * * /opt/dbvisit/standby/dbvisit SGDEV1
#
# Standby database dbvisit apply log files
00,10,20,30,40,50 * * * * /opt/dbvisit/standby/dbvisit SGPRD2
00,10,20,30,40,50 * * * * /opt/dbvisit/standby/dbvisit SGDEV2

4.4 Archive log management

Primary Server
Archive log management is always managed by RMAN backups on the primary
server. The standard retention period of backups is 4 weeks on the Netbackup
server. However archive logs will be deleted from the disk file system after 4 days.
The period of 4 days is taken to cover issues during a long weekend. If however
archive logs have been deleted before they have been send over to the Standby
Server, a restore from RMAN backup of the required archive log files would be
required.
Standby Server
Archive log management is handled by DBVisit. After the archive log file is received
and applied to the standby database, DBVisit compresses the archive log file. Archive
log files are then removed after 4 days.

Page | 13
5 Using DBVisit
5.1 Resending archive logs
If for any reason the specific log files from the primary database have to be resent to
the standby database the following command can be used.
On the primary database server:
dbvisit -r <sequence_number> <DDC>
Where DDC is the name of the DB visit Database Configuration. In most cases this is
the same as the database name. The DDC refers to the DDC file name which is in the
form: dbv_DDC.env and contains the Dbvisit Standby settings for a particular primary
and standby configuration.
Where sequence_number is the log sequence number from which you want to start
sending.
For example:
dbvisit -r 229 SGPRD1
======================================================
Dbvisit Standby Database technology
dbvisit started on dbvisit11
======================================================

Log file(s) for SGPRD1 will be transferred from dbvisit11 to dbvisit12...

200608292337 - 5 Log transfer(s) for SGPRD1 completed.
Last sequence was 233.

======================================================
dbvisit ended on dbvisit11
======================================================

Where dbvisitp is the name of the database, and 229 is the starting
log sequence number to resend.

5.2 Archivelog mode switched off

When a database is taken out of archivelog mode, log shipping does not occur
anymore and the standby database will technically be invalid. When transactions
have occurred and a log switch has taken place, there is no simple way of bringing
the primary database back in archivelog mode and start shipping log files to the
standby database. In this case the standby database needs to be rebuild from the
primary database.

Page | 14
 This can be done in a number of ways, but the easiest way is in the following steps
- On the standby server shutdown the database and remove database files,
controlfiles and archive log files. For example for SGDEV1 the files can be found
in the following directories
/oracle/oradata/SGDEV1
/opt/oracle/fast_recovery_area/SGDEV1
/oracle/archive/SGDEV1

- Connect to the database as sysdba

- Issue the command

alter system switch logfile

- Create a new standby controlfile

alter database create standby controlfile as ‘/tmp/sgdev1_control01.ctl’;

- Shutdown the primary database

- Copy the standby control file and database file to the standby server
scp ‘/tmp/sgdev1_control01.ctl’ oracle@sgporab:/oracle/oradata/SGDEV1
scp ‘/tmp/sgdev1_control01.ctl’
oracle@sgporab:/opt/oracle/fast_recovery_area/SGDEV1/sgdev1_control02.ctl
scp /oracle/oradata/SGDEV1/*.dbf oracle@sgporab:/oracle/oradata/SGDEV1

- Restart the primary database

- Start the standby database in standby recovery mode

/opt/dbvisit/standby/dbv_oraStartStop start SGDEV1

- Make sure that dbvisit cronjob is enabled on both primary and standby server

5.3 Graceful Switchover (role reversal)

Graceful Switchover (GS) is also referred to as role reversal or switchover. It is not
the same as failover.
Graceful Switchover is used to switch back to the original
primary database after a disaster in which the standby database has been
activated. 
Graceful Switchover might also be used for planned outages to perform
an upgrade on the primary site by switching over the database users to the standby
site as hardware or software is upgraded on the primary site. It may also be used to
test the Disaster Recovery scenario. During a switchover, the primary database
transitions to a standby role, and the standby database transitions to the primary
role. There is no loss of data during the transition and the standby database does not
have to be rebuilt. 
After the planned outage is completed, Graceful Switchover can
reverse back to the original state.
Note 1: Always ensure you have a valid backup before initiating Graceful Switchover.


Note 2: Graceful Switchover supports different structures between the primary and
standby database. The standby database files or redo logs may be in different
directory structure (mount points) as the primary database and have different file
names. The standby database must however have the same number of data files as
the primary database. 

How the Dbvisit Standby Graceful Switchover process works
1. Dbvisit Standby checkpoints are used to ensure the process between the
primary and standby database are synchronised.Users should be disconnected
from the main primary database.
2. Dbvisit Standby Graceful Switchover is initiated with a simple command on the
primary server and the standby server.
3. Main primary database is shutdown during transition.

Page | 15
4. Standby database is shutdown during transition.
5. Main primary database transitions to standby database on primary server in
matter of minutes*.
6. Standby database transitions to primary database on standby server in matter of
minutes*.
7. Users can re-connect to primary database on standby server and continue
working, with no data loss.
8. Maintenance can proceed on primary server.
9. Optionally Dbvisit Standby can keep the standby database on the primary server
up to date during the scheduled maintenance outage.
10. At the end of the scheduled maintenance the databases are transitioned back to
their original state in matter of minutes*.
Prerequisites
1. Ensure Dbvisit Standby is no longer scheduled on the primary and standby
servers.
2. Ensure there is enough space on the standby server to receive the primary redo
logs, and any new archive logs created.
3. Ensure that the standby database is in archive log mode.
4. Ensure there is sufficient space on the primary server for complete backups of
the redo logs. Required space will be double the current redo log space
requirements.
5. The standby database must be up to date before starting the switchover
process. Dbvisit Standby will check if this is the case and will not initiate the
switchover if the standby database is not up to date.

6. Oracle database parameters db_file_name_convert and log_file_name_convert

must be set to default values (null strings) in the primary database prior to
switchover. If either of the parameters are set to non null values in an Oracle
database version 11 and higher that uses an spfile (not pfile), Dbvisit will
automatically reset both parameters to default values during Graceful
Switchover so no action is required.To ensure standby database is up to date,
run Dbvisit Standby manually on both primary and standby databases.

7. The standby database must be available. Dbvisit Standby will check if this is the
case and will not initiate the switchover if the standby database is not available.

Switchover
1. On the primary server start the Graceful Switchover procedure.
dbv_oraStartStop switchover SGPRD1
Where dbvisitp is the name of the database

2. On the standby server start the Graceful Switchover procedure.Where SGPRD1 is

the name of the database
dbv_oraStartStop switchover SGPRD1
Where dbvisitp is the name of the database

3. Enter a unique key on the primary server. This unique key can be any number that
has not previously been used for Graceful Switchover. Dbvisit Standby will notify if a
previously used key is used.

4. Enter the same unique key on the standby server. This ensures that both
processes are linked to each other.

Page | 16
 5. At the end of the switchover, the primary database has transitioned to a standby
database and the standby database has transitioned to a primary database.

5.4 Failover
When disaster strikes and the primary database is no longer available the standby
database must be activated to become the new primary database to continue
operation.
This is also called failover to the standby database.
The steps to activate the standby database are:
- Stop the scheduling of Dbvisit Standby.
- Change the network configuration (or DNS) so that users will connect to the
standby database (or server) instead of the primary database (or server).
- Activate and open the standby database for normal operation as per instructions
below. As soon as the standby database is activated and becomes the new active
primary database, the link to the original primary database is lost and it is no
longer possible to apply new logs to the original primary database.
To activate and open the standby database for continued operation in the event of a
disaster the following procedure must be used:
On the standby server
- Manually run Dbvisit Standby to ensure all log files have been applied.
dbvisit SGPRD1
- Activate the standby database. A prompt will be displayed to ask for confirmation:
dbv_oraStartStop activate SGPRD1
- As soon as possible, back up your new production database. At this point, the
former standby database is now your production database. This task, while not
required, is a recommended safety measure because you cannot recover changes
made after activation without a backup.

5.5 DBVisit Housekeeping

Temp files
Dbvisit Standby produces temporary files in the TMP* directory every time Dbvisit
Standby executes. 
The temporary files are automatically deleted when Dbvisit
Standby finishes execution.
If REMOVE_TEMP_FILE is set to N (default is Yes), then
all temporary files will be NOT be deleted when Dbvisit Standby has completed
processing. This setting does not apply to Dbvisit Standby trace files. These will
always be created.
Dbvisit Standby trace files
Dbvisit Standby trace files are files that are created every time Dbvisit Standby
executes. Dbvisit Standby trace files can be sent to Dbvisit support for fast issue
resolution.
Trace files are created in the TMP* directory. The trace filename will
start with a number, then the name dbvisit, then the database name and then the
timestamp and will end with extension .trc.

Example: 

3118_dbvisit_prod10g_200901091322.trc


Dbvisit Standby trace files are automatically deleted according to settings:

NUM_TRACE_TO_KEEP
= The number of trace files to keep after which trace files are deleted.

DAYS_TO_KEEP_TRACE
= The number of days to keep the trace files after which trace files are deleted.

Default settings are:

NUM_TRACE_TO_KEEP = 100 
DAYS_TO_KEEP_TRACE = 10

Page | 17
Least restrictive setting applies between DAYS_TO_KEEP_TRACE and
NUM_TRACE_TO_KEEP. 
To turn off, set to 0.
Prior to version 5.1.19 Dbvisit
Standby trace files are not removed.

Dbvisit Standby log files

The Dbvisit Standby log file (dbvisit.hist) and the Dbvisit Standby archive
management module log file (<DDC>_arch_management.log) will automatically be
kept at a specific size based on the following settings:

LOG_FILE_ROTATE_MAX

LOG_FILE_SIZE_MAX_MB

LOG_FILE_ROTATE_MAX indicates how many backups are made of the log files
before it is overwritten.
The first backup will be: dbvisit_hist.log.1
The second backup will be: dbvisit_hist.log.2
etc.
LOG_FILE_SIZE_MAX_MB indicates the size of the log file before the log file is
rotated as above. 


Example:

LOG_FILE_ROTATE_MAX = 5

LOG_FILE_SIZE_MAX_MB = 5

This setting ensures the maximum size of the Dbvisit Standby log file will be 5MB. If
the log file is greater than 5MB, it will be copied to a backup log file. 
This setting
ensures there will be 5 backup versions of the Dbvisit Standby log file before backup
versions of the log file will be overwritten.
The TMP directory location can be found in the DDC file for the database.

Page | 18
6 Using DB Visit to Sync Standby Database
using Incremental Backup
STEP 1:- Create Directory on primary & standby server to take incremental backup.

STEP 2:- On the Primary Node ( Primary Server) execute the “dbvsit_setup” command
Cd /opt/dbvisit/standby/

STEP 3:- Once the setup is executed. It will ask you for a confirmation

Select Yes, as this can be executed only from primary Node. I have captured the
screenshot from Stack B just for the reference

STEP 4:- Once confirmed It will ask for further options

Page | 19
Select Option 8 to synchronise standby database
STEP 5:- Select the database

STEP 6:- It will ask for a confirmation

Page | 20
 Enter yes as choice

STEP 7:- Process will Query both Primary and standby database and
show the lag results and ask for confirmation to proceed

STEP 8:- Specify the location on Primary and Standby server where
RMAN can take the backups. This was the first step, which we did in this
process.

Page | 21
STEP 9:- DB Visit will now automatically perform the database sync and
update DB Visit Catalog.

Page | 22
STEP 10:- Stop the standby database using DB Visit on stack b.

Page | 23
STEP 11:- Start the standby database using DB Visit on stack b.

Page | 24
Appendix A – Scripts
oracle
#!/bin/sh
#
# /etc/rc.d/init.d/oracle
# Description: Starts and stops the Oracle database, listeners and Enterprise
Manager
# See how we were called.
case "$1" in
start)
echo "Starting Oracle" >> /var/log/oracle
echo "................." >> /var/log/oracle
date " %T %a %D : Starting Databases as part of system up." >> /var/log/oracle
echo "................." >> /var/log/oracle
#
# Oracle start and stop done via OraStartStop to handle standby databases
correctly
# echo -n "Starting Oracle Databases: "
# su - oracle -c dbstart >> /var/log/oracle
#echo "Done."
echo -n "Starting Oracle Listeners: "
su - oracle -c "lsnrctl start" >> /var/log/oracle
echo "Done."
#echo -n "Starting Oracle Enterprise Manager: "
#su - oracle -c "emctl start dbconsole" >> /var/log/oracle
#echo "Done."
echo ""
echo ".................-" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo ".................-" >> /var/log/oracle
touch /var/lock/subsys/oracle
;;
stop)
echo "Shutting Down Oracle"
echo ".................-" >> /var/log/oracle
date +"! %T %a %D : Shutting Down Oracle Databases as part of system down." >>
/var/log/oracle
echo ".................-" >> /var/log/oracle
#echo -n "Shutting Down Oracle Enterprise Manager: "
#su - oracle -c "emctl stop dbconsole" >> /var/log/oracle
#echo "Done."
echo -n "Shutting Down Oracle Listeners: "
su - oracle -c "lsnrctl stop" >> /var/log/oracle
echo "Done."
rm -f /var/lock/subsys/oracle
#echo -n "Shutting Down Oracle Databases: "
#su - oracle -c dbshut >> /var/log/oracle
#echo "Done."
echo ""
echo ".................-" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo ".................-" >> /var/log/oracle
;;
restart)
echo "Restarting Oracle"
echo ".................-" >> /var/log/oracle
date +"! %T %a %D : Restarting Oracle Databases as part of system up." >>
/var/log/oracle
echo ".................-" >> /var/log/oracle
#echo -n "Restarting Oracle Databases: "
#su - oracle -c dbshut >> /var/log/oracle
#su - oracle -c dbstart >> /var/log/oracle
#echo "Done."
echo -n "Restarting Oracle Listeners: "
su - oracle -c "lsnrctl stop" >> /var/log/oracle
su - oracle -c "lsnrctl start" >> /var/log/oracle
echo "Done."
#echo -n "Restarting Oracle Enterprise Manager: "
#su - oracle -c "emctl stop dbconsole" >> /var/log/oracle
#su - oracle -c "emctl start dbconsole" >> /var/log/oracle
#echo "Done."
echo ""
echo ".................-" >> /var/log/oracle
date +"! %T %a %D : Finished." >> /var/log/oracle
echo ".................-" >> /var/log/oracle
touch /var/lock/subsys/oracle
;;
*)

Page | 25
echo "Usage: oracle {start|stop|restart}"
exit 1
esac

Page | 26
OraStartStop
#!/bin/sh
#
# description: w120n database is started and stopped using dbvisit
#
prog=dbv_oraStartStop
start () {
echo -n $"Starting $prog: "
su - oracle -c "/opt/dbvisit/standby/$prog start SGPRD1"
su - oracle -c "/opt/dbvisit/standby/$prog start SGPRD2"
su - oracle -c "/opt/dbvisit/standby/$prog start SGDEV1"
su - oracle -c "/opt/dbvisit/standby/$prog start SGDEV2"
}
stop () {
echo -n $"Stopping $prog: "
su - oracle -c "/opt/dbvisit/standby/$prog stop SGPRD1"
su - oracle -c "/opt/dbvisit/standby/$prog stop SGPRD2"
su - oracle -c "/opt/dbvisit/standby/$prog stop SGDEV1"
su - oracle -c "/opt/dbvisit/standby/$prog stop SGDEV2"
}
restart () {
echo -n $"Restarting $prog: "
su - oracle -c "/opt/dbvisit/standby/$prog restart SGPRD1"
su - oracle -c "/opt/dbvisit/standby/$prog restart SGPRD2"
su - oracle -c "/opt/dbvisit/standby/$prog restart SGDEV1"
su - oracle -c "/opt/dbvisit/standby/$prog restart SGDEV2"
}
status () {
echo -n $"Status $prog: "
su - oracle -c "/opt/dbvisit/standby/$prog status SGPRD1"
su - oracle -c "/opt/dbvisit/standby/$prog status SGPRD2"
su - oracle -c "/opt/dbvisit/standby/$prog status SGDEV1"
su - oracle -c "/opt/dbvisit/standby/$prog status SGDEV2"
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
status)
status
;;
*)
echo $"Usage: $prog {start|stop|restart|status}"
exit 3
esac

Page | 27
Appendix B – Technical Requirements
The virtualisation detailed design document is in line with the below mentioned
design principals specified by Endeavour Energy as business objectives.
Business Objectives Technical Requirement

High Availability The architecture and infrastructure that

supports the Smart Grid must operate on a 24x7
basis with each system that forms part of the
Smart Grid providing better than 99.95%
availability. In order for the systems (that is the
combination of infrastructure and software) to
provide this level of availability, the supporting
infrastructure must achieve an availability rate
in excess of 99.995%.
Scalability The Smart Grid will be rolled out over a period
of seven to ten years. During this time, the
supporting infrastructure must scale smoothly
to accommodate each stage of the roll-out. The
pilot Smart Grid area represents between two
and three percent of the overall network. This
means that the initial architecture for the Smart
Grid pilot must be capable of scaling by nearly
two orders of magnitude.
Cost Effectiveness The architecture must be cost effective as it is
scaled to meet the demands of the final roll-out.
The architecture should avoid expensive
proprietary technologies, technology lock-in and
unfavourable license models each of which
could make the cost of the infrastructure to
meet the final roll-out prohibitively expensive.
Performance The majority of the Smart Grid systems such as
distribution automation, demand response,
outage management, power system analysis are
required to operate in real-time. It is of critical
importance that these systems reliably provide
high levels of performance during high loads
such as during storms, peak demand or other
network constraint conditions that place the
overall network under stress.
Security The Smart Grid is highly interconnected and, for
the first time, connects all customers and
network devices via a high-speed wide area
network. This increases the number of potential
points of attack and areas of vulnerability. The
architecture must provide high levels of
protection against external and malicious attack
and protect against inadvertent mal-operation
or misuse.
Agility and Flexibility It is anticipated that over the course of the
Smart Grid roll-out, new technologies, business
requirements and applications will emerge. The
architecture must be agile and flexible enough

Page | 28
Business Objectives
Supportability
Immunity and Interoperability
Technical Requirement
to accommodate such changes.
Endeavour Energy currently only has a small
number of systems that require 24x7 support.
Smart grid will significantly increase the number
of systems that fall into this category. It is
important that the proposed architecture is
straightforward and cost-effective to support,
maintain and upgrade. The roll-out of the Smart
Grid pilot architecture will require new support
model to be developed that provides the
business the service levels that are required.
The Smart Grid systems must be capable of
interoperating with Endeavour core IT systems.
However, the Smart Grid architecture and its
supported systems must be immune to system
loads and outages within the core IT
infrastructure. Conversely, the Smart Grid
systems must not impact on the performance or
availability of Endeavour’s core IT systems.
Page | 29