Professional Documents
Culture Documents
The information in this manual is subject to change without notice. All statements, information and recommendations in
this manual are believed to be accurate, but are presented without warranty of any kind, expressed or implied. Users
must take full responsibility for their use of any products.
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical,
including photocopying and recording, or by any information storage or retrieval system, without prior written consent
from SR Telecom Inc.
SR TELECOM, AIRSTAR, ANGEL, INSIGHT NMS, METROFLEX, METROPOL, SR500, SR500IP, SWING, SYMMETRY
and WL500 are trademarks of SR Telecom Inc. All rights reserved 2005. All other trademarks are property of their
owners. Information subject to change without notice.
2005, SR Telecom Inc.
All rights reserved. 5/30/05
Printed in Canada
Head Office
SR Telecom Inc.
8150 Trans-Canada Hwy.
Montreal, Quebec
Canada H4S 1M5
Tel.: +1 514 335 1210
Fax: +1 514 334 7783
1 888 SRTELECOM (778 3532)
(U.S. and Canada)
www.srtelecom.com
Table of Contents
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Introduction .............................................................................................................................................. 5
1.1
Introduction ......................................................................................................................... 6
1.2
1.3
1.4
1.5
1.6
1.7
2.2
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.4
2.4.1
2.4.2
2.4.3
2.4.4
3.2
4.2
Chapter 6
5.2
5.3
5.4
6.2
6.3
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.5
6.6
6.6.1
6.6.2
Chapter 1
Introduction
This chapter introduces some basic database concepts that you need to understand in
order to effectively use the tools. Chapter 2 describes a monitor tool that checks the
health and state of the NMS database and sends out reports using e-mail. Chapter 3
describes how to install and perform NMS database cold backup, and Chapter 4
describes how to install and perform NMS database hot backup. Chapter 5 describes
how to restore an NMS database from backups and suggests the preparation steps
that you should follow to reduce the database recovery time as well as restore
database 100%. Chapter 6 describes how to prepare, manage, and maintain an
Oracle standby database using SYMMETRY NMS.
1.1
Introduction
One of the most important tasks for SYMMETRY NMS system administrators is to protect the NMS
database from failures. Particularly, the database must be backed up frequently so that the database
can be restored in the event of media failure. SYMMETRY NMS provides tools to help system
administrators maintain database operations. This document describes these tools and how to use
them.
The SYMMETRY NMS Database Maintenance Guide also contains some information about common
database maintenance tasks, including how to purge old Raphael data records, how to purge old NMS
alarm history records and event records. It also explains how to schedule these tasks to run
automatically. It is important for a system administrator to perform these tasks to ensure proper NMS
operations.
d
1.2
All database system files described in this chapter must not be modified by anyone. Doing so
will cause the NMS database to be corrupted.
Introduction
1.3
1.4
1.5
1.6
1.7
Chapter 2
2.1
Login NMS server as user oracle and copy the supplied monitor.tar file to /tmp.
2.
Run the install script to install and configure the NMS database monitor.
%/tmp/installmonitor.ksh
When prompted, please be sure to enter correct e-mail address(es). NMS database monitor will
send reports to the specified e-mail address(es). Multiple e-mail addresses must be separated by a
space.
4.
10
2.2
2.
4.
If you have performed the above steps correctly, you should automatically receive NMS database
reports via e-mail, as scheduled.
11
2.3
2.3.1
Error Alerts
The error alert section lists all Oracle errors that have been generated since yesterday. For example, the
following error alerts indicate that the Oracle database was not able to insert new alarm history records
because it was unable to extend the tablespace. Therefore, old alarm history records need to be purged
to make room for new ones, or the tablespace needs to made larger.
<< Alert Errors Since Yesterday >>
ORA-1653: unable to extend table GMS_S1.ALARMHISTORY by 1024 in tablespace ALMA_DATA
ORA-1653: unable to extend table GMS_S1.ALARMHISTORY by 1024 in tablespace ALMA_DATA
All errors in the error alerts section should be investigated and addressed immediately.
2.3.2
12
2.3.3
f
2.3.4
You can ignore the warnings related to tablespace raphael_dimension_data, for example,
RAPHAEL_DIMENSION_DATA : RAPHAEL.DAY (TABLE, next_extent 8388608). This
tablespace is no longer used.
13
2.3.5
14
2.4
Preventive Actions
The following sections describe the common maintenance tasks that you may need to perform when
addressing the issues reported in the NMS database monitor report.
2.4.1
2.
Invoke Oracle server manager tool by typing svrmgrl to get SVRMGR prompt.
3.
At SVRMGR prompt, type in the following commands. Press the return key or ENTER after each
command.
SVRMGR>connect internal
SVRMGR>select file_name from dba_data_files where tablespace_name='GMS_DATA';
Note the semicolon at the end of the select command above. The select command gives you a file
name. This is the name of the data file for the tablespace. In this example, for tablespace
GMS_DATA, the data file would be /data/oradata/GMS/gms_data01.dbf.
4.
? Take note of the file size for /data/oradata/GMS/gms_data01.dbf file. For example, let us assume
that it is 150 MB.
15
Return to the terminal window with the SVRMGR prompt and type in the following command at the
SVRMGR prompt:
SVRMGR>alter database datafile '/data/oradata/GMS/gms_data01.dbf' resize 210M;
Note the single quotes between the file name. The above command will take a short while and it will
increase the file size from 150 MB to 210 MB.
6.
7.
Verify the file size change for /data/oradata/GMS/gms_data01.dbf by entering the following
command:
ls -l /data/oradata/GMS
16
2.4.2
Coalescing a Tablespace
Assume that the NMS database monitor report has entries as described in Section 2.3.4 on page 13.
Coalesce a tablespace to try to reduce space fragments.
To coalesce the tablespace RAPHAEL_CDR_DATA_P1
1.
2.
Invoke Oracle server manager tool by typing svrmgrl to get SVRMGR prompt.
3.
At SVRMGR prompt, type in the following commands. Press the return key or ENTER after each
command.
SVRMGR>connect internal
SVRMGR>set heading off
SVRMGR>set pagesize 0
SVRMGR> select 'alter table ' || owner || '.' || segment_name || ' deallocate
unused;' from dba_segments where tablespace_name = 'RAPHAEL_CDR_DATA_P1;
The above select command provides one or more alter table statements for each table in the
tablespace RAPHAEL_CDR_DATA_P1:
alter table RAPHAEL.VOICE_CDR_SEGMENT deallocate unused;
alter table RAPHAEL.RU_CDR_SEGMENT deallocate unused;
alter table RAPHAEL.VOICE_V52_MEASUREMENT deallocate unused;
4.
Cut and paste the above alter table commands at the prompt, one by one, to execute them.
5.
17
2.4.3
2.
Invoke Oracle server manager tool by typing svrmgrl to get SVRMGR prompt.
3.
At SVRMGR prompt, type in the following commands. Press the return key or ENTER after each
command.
SVRMGR>connect internal
SVRMGR>alter table raphael.base_call_util_measurement storage (maxextents
unlimited);
SVRMGR>exit
2.4.4
Before you rebuild a tablespace, you must stop the Raphael loading processes.
18
Login as user gabriel and invoke stopraphael to stop the Raphael loading processes.
2.
Confirm that the Raphael parser (dta) and loader processes (rdm) are stopped using the following
UNIX command:
ps -ef | grep dta and ps -ef | grep rdm
2.
Place the export parameter file (exp_rap_cdr_data_p1) and import parameter file
(imp_rap_cdr_data_p1) in the new directory exp_imp.
3.
After the export is completed, there should be a export dump file called cdr_data_p1.dmp and a log
file called exp_cdr_data_p1.log.
4.
Review the log file to make sure that the export has been finished before you continue. Do not
attempt to view the dump file.
5.
Truncate the tables and coalesce the tablespace. Truncating a table deletes all the records and also
reset its storage parameter to the initial values when the table was created. This will cause the new
records to be inserted from the beginning of the data file.
%svrmgrl
SVRMGR>connect internal
SVRMGR>truncate table RAPHAEL.VOICE_CDR_SEGMENT;
SVRMGR>truncate table RAPHAEL.RU_CDR_SEGMENT;
SVRMGR>truncate table RAPHAEL.VOICE_V52_MEASUREMENT;
SVRMGR>alter tablespace RAPHAEL_CDR_DATA_P1 coalesce;
SVRMGR>exit
6.
Import back.
%imp sys/live parfile=imp_rap_cdr_data_p1
19
File exp_rap_cdr_data_p1:
DIRECT=Y
ROWS=Y
CONSISTENT=Y
COMPRESS=N
STATISTICS=NONE
RECORDLENGTH=57344
#THE FOLLOWING PARAMETERS ARE TABLE OR TABLESPACE SPECIFIC
FILE=cdr_data_p1.dmp
LOG=exp_cdr_data_p1.log
TABLES=(RAPHAEL.VOICE_CDR_SEGMENT, RAPHAEL.RU_CDR_SEGMENT,
RAPHAEL.VOICE_V52_MEASUREMENT)
File imp_rap_cdr_data_p1:
FROMUSER=RAPHAEL
TOUSER=RAPHAEL
IGNORE=Y
#THE FOLLOWING PARAMETERS ARE TABLE OR TABLCESPACE SPECIFIC
FILE=cdr_data_p1.dmp
LOG=imp_cdr_data_p1.log
20
Chapter 3
21
3.1
Login NMS server as user oracle and copy the supplied backup_cold.tar file to /tmp.
2.
Extract the tar file using the following UNIX tar command:
%cd /tmp
%tar xvf backup_cold.tar
Run the install script to install and configure the NMS database cold backup tool.
%/tmp/installcoldbackup.ksh
22
3.2
Login NMS server as user gabriel and shutdown all NMS applications.
%stopgabriel
%stopraphael
%stopmichael
2.
Ensure that all NMS GUI applications are closed, particularly any NMS Admin Viewer and Raphael
PM Viewer since they access database directly. Do not shutdown the Oracle database.
f
3.
You must leave the database up and running as the cold backup scripts will need to access
the database before it starts the backup. The scripts will shutdown the database during the
cold backup and will restart the database after the cold backup is completed.
The time it takes to complete the cold backup depends on the size of the NMS database. You can
monitor the backup progress by tailing the backup log file.
23
2.
The actual log file name for the tail command will be different. The above example assumes that
you are performing the cold backup on Feb 11, 2004. When the cold backup completes, the log file
will print lines to inform you. You should receive an e-mail at the e-mail address(es) that you have
specified when you installed the NMS database monitor tool.
The backup files are located in /export/apps/oracle/admin/GMS/bkup/cold. This directory also contains
the restore scripts, that were generated during the backup, that will be required to restore the database
from these backup files. This is the directory that you should tar up and save a copy on another disk or
on tape every time that you complete a cold backup.
24
Chapter 4
25
4.1
You should perform a database cold backup before attempting the steps listed here. This
ensures that you can always restore the database to the current state using the cold backup, if
necessary. For information about performing a database cold backup, refer to the steps in
Chapter 3.
Login NMS server as user gabriel and shutdown all NMS applications.
%stopgabriel
%stopraphael
%stopmichael
2.
Ensure that all NMS GUI applications are closed, particularly any NMS Admin Viewer and Raphael
PM Viewer, since they access the NMS database directly. Do not shutdown the Oracle database.
You must leave the database up and running. The hot backup installation scripts need to
access to the database. The database will be restarted automatically when the installation
completes.
3.
Login NMS server as user oracle and copy the supplied backup.tar file to /tmp.
4.
26
Run the install script to install and configure the NMS database hot backup tool.
%/tmp/installbackup.ksh
This script will shutdown the NMS database and restart it in archive log mode to allow for the
backing up of the database while it is online. Please be patient while waiting for the script to
complete, as a proper database shutdown may take a little while.
6.
The output of the last SVRMGR command should show that: the database is in archive mode, the
automatic archival is enabled, the archive destination is set to
/export/apps/oracle/admin/GMS/multiplex/archives/.
7.
You have just installed the NMS database hot backup tool. You can now restart NMS applications. Login
as user gabriel and follow the steps described in the Software Installation Setup Guide to start Gabriel,
Michael Order Manager, and Raphael.
To confirm the successful installation, you should perform a NMS database hot backup right away.
27
4.2
2.
The time it takes to complete the hot backup will depend on the size of the NMS database. You can
monitor the backup progress by tailing the backup log file.
To monitor backup progress
1.
2.
The actual log file name for the above tail command will be different. The above example assumes
that you are performing the hot backup on Feb 11, 2004. When the hot backup completes, the log
file will print lines to inform you. You should also get an e-mail at the e-mail address(es) that you
have specified when you installed the NMS database monitor tool.
The backup files are located in /export/apps/oracle/admin/GMS/bkup/hot. This directory also
contains the restore scripts, that were generated during the backup, that will be required to restore
the database from these backup files. This is the directory that you should tar up and save a copy
on another disk or on tape every time you that complete a hot backup. This step can be automated
by using UNIX cron to schedule daily hot backups, followed by simple UNIX tar and move
commands.
28
Chapter 5
29
5.1
If necessary, reinstall the entire SYMMETRY NMS. This is required if the entire NMS is lost due to a
disk crash. You may also need to install and configure Solaris if the damaged disk also hosted the
OS. Refer to the Software Installation Setup Guide provided with your SYMMETRY NMS system to
install the OS and SYMMETRY NMS. Installing the OS alone may take several hours. To reduce
NMS downtime, you should have a second Sun server available, with the OS and the NMS installed
and ready to use.
2.
If necessary, reinstall the NMS database monitor and backup tools. Follow the installation
instructions in Chapter 2 and Chapter 3, respectively. Note that you may need to start up the
database first before installing the NMS database monitor and backup tools. This step can be
avoided by having another server available with the NMS database monitor and backup tools
already installed.
3.
Ensure that all NMS applications have been stopped. Login as user gabriel and follow the steps in
the Software Installation Setup Guide to shutdown the Gabriel, Raphael, and MOM applications.
4.
Login in as user oracle and make sure that the database and its listener have all been stopped.
Follow the steps in the Software Installation Setup Guide to check this and issue the proper stop
commands. If you are not able to shutdown the database using the SVRMGR shutdown immediate
command described in the Software Installation Setup Guide, you will have to use the shutdown
abort command.
5.
Get the last cold backup files and place them in the following directory:
/export/apps/oracle/admin/GMS/bkup/cold. In addition to other files, there are two restore scripts in
this directory and their names depend upon the date when the cold backup was taken. Make sure
that you are still logged in as user oracle and perform the following two commands to change them
to be executable:
%cd /export/apps/oracle/admin/GMS/bkup/cold
%chmod u+x restore_cold_backup_11Feb04.sh
%chmod u+x restore_cold_backup_GMS_11Feb04.sh
The above commands assume that the cold backup was taken on Feb 11, 04.
30
The first script restores the database configuration parameter files and takes very little time. The
second script restores the database data files; the time it takes depends on the size of the
database. As the second script executes, it reports the progress status and you should start to see
the data files appearing in the directories under /data/oradata.
7.
After the restore scripts complete the execution, verify that the Oracle files tnsnames.ora and
listener.ora have the correct host name. This is particularly important if you are using a cold backup
file taken on a different host.
% cd $TNS_ADMIN
You will see the two files in this directory. Make proper changes if the values for variable HOST in
these two files do not match the correct name of the host.
8.
You can proceed to start up the NMS database and applications. Please follow the instructions in
the Software Installation Setup Guide provided with your SYMMETRY NMS system.
31
5.2
If you have copies of the latest online redo logs, archive logs, and control files, the hot backup
restore is also easier and you can recover the changes made after the hot backup was taken. If
this is the case, ensure that you make and store a copy of these file somewhere. Do not put
them in /data/oradata/GMS and /export/apps/oracle/admin/GMS/multiplex, since these
locations will be overwritten during the steps below. Refer to Section 5.4 Restoring the NMS
Database Completely on page 37.
32
1.
If necessary, reinstall the entire SYMMETRY NMS This is required if the entire NMS is lost due to a
disk crash. You may also need to install and configure Solaris if the damaged disk also hosted the
OS. Refer to the Software Installation Setup Guide provided with your SYMMETRY NMS system to
install the OS and SYMMETRY NMS. Installing the OS alone may take several hours. To reduce
NMS downtime, you should have a second Sun server available, with OS and NMS installed and
ready to use.
2.
If necessary, reinstall the NMS database monitor and backup tools. Follow the installation
instructions Chapter 2 and Chapter 4, respectively. Note that you may need to start up the
database first before installing the NMS database monitor and backup tools. This step can be
avoided by having another server available with the NMS database monitor and backup tools
already installed.
3.
Ensure that all NMS applications have been stopped. Login as user gabriel and follow the steps in
the Software Installation Setup Guide to shutdown the Gabriel, Raphael, and MOM applications.
4.
Login in as user oracle and make sure that the database and its listener have all been stopped.
Follow the steps in the Software Installation Setup Guide to check this and issue the proper stop
commands. If you are not able to shutdown the database using the SVRMGR shutdown immediate
command described in the Software Installation Setup Guide, you will have to use the shutdown
abort command.
Get the last hot backup files and place them in the following directory:
/export/apps/oracle/admin/GMS/bkup/hot. In addition to other files, there is a restore script in this
directory and its name depends upon the date when the hot backup was taken. Make sure that you
are still logged in as user oracle and perform the following command to change it to be executable:
%chmod u+x restore_GMS_11Feb04.sh
The above command assumes that the hot backup was taken on Feb 11, 04.
6.
If you have copies of the latest control file, redo log files, and archived redo log files, stop
here and do not perform the steps below. Refer to the steps in Section 5.4 Restoring the
NMS Database Completely on page 37 to continue so that even the changes after the hot
backup was taken can be restored.
Run the restore script to restore database data files, archive logs, and database parameter files.
You must specify the database name GMS on the command line.
%./restore_GMS_11Feb04.sh GMS
7.
The hot backup cannot directly copy the database control files because hot backup is performed
while database is open and running. The steps given here will create the control files back from a
control file trace created during the hot backup. You can avoid losing control files so that these
steps here will not be necessary. Having a most recent control file also ensures a safe database
recovery. There are ways for maintaining a copy of a recent control file and they will be discussed in
a later section. Follow the steps below to recreate the database control files from the trace file.
%cp control_GMS_11Feb04.sql /data/oradata/GMS
This copies the control trace file created during the hot backup to the original location of the control
file.
33
Edit the file control_GMS_11Feb04.sql in /data/oradata/GMS to comment out the last line by adding
-- (two dashes) to the beginning of the line. After this is done, the last line should read as:
-- ALTER DATABASE OPEN RESETLOGS;
It is important to comment out this line before you continue with the next step.
9.
10. Type and enter AUTO and all of the archive logs which are present in the backup will be applied.
After all of the available logs have been applied, you may see some error message like:
ORA-00308: cannot open archived log
'/export/apps/oracle/admin/GMS/multiplex/archives/1_101.gms'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
This means that archive log file it is looking for is not there. If this number is higher than the
numbers in the archive log directory, it is acceptable because it has not been written to disk yet.
At this point, the database has been recovered. Because the control file was recreated, you must
synchronize the data files with the control files and redo log files.
34
12. At this point you should perform a cold backup of the database before launching the NMS. This
ensures that you can easily restore the database up to this point using the cold backup. Follow the
instructions provided in Chapter 3 to perform a cold backup.
At the end of the cold backup, the database will be restarted automatically.
13. Restart the listener as user oracle.
%lsnrctl start
You may need to wait for a minute or so for the above command to work, since Oracle listener takes
a little while to start up.
15. Follow the Software Installation Setup Guide provided with your SYMMETRY NMS system to start
up the NMS applications.
35
5.3
36
5.4
37
Make sure that you make and store a copy of the latest redo logs, archived redo logs, and control
file somewhere. Do not put them in /data/oradata/GMS and
/export/apps/oracle/admin/GMS/multiplex, since these locations will be overwritten during steps
below.
2.
Refer to Section 5.2 on page 32 and complete Step 1 on page 32 to Step 5 on page 33.
3.
Run the restore script to restore database the data files, archive logs, and database parameter files
from the hot backup. You must specify the database name GMS on the command line.
%./restore_GMS_11Feb04.sh GMS
4.
Place a copy of the control files, latest redo log files, and archive log files in both locations,
/data/oradata/GMS and /export/apps/oracle/admin/GMS/multiplex.
5.
This restores the database including the changes that have taken place since your last hot backup. After
this step, continue with the remaining steps described Section 5.2 Restoring the NMS Database from a
Hot Backup on page 32 to perform a cold backup, to start the database listener, and to start NMS
applications (Step 12 on page 35 to Step 15 on page 35).
38
Chapter 6
39
6.1
Figure 6.1
40
6.2
Figure 6.2
41
Figure 6.3
42
6.3
To use the standby NMS feature, you must install the NMS database monitor, cold backup, and
hot backup tools on the primary database. If you have not done so, you should first install them
on the primary host and perform some monitor and backup operations before continuing to set
up the standby database. Refer to Chapter 2, Chapter 3, and Chapter 4.
Install a complete SYMMETRY NMS system on the standby host, including the NMS database
maintenance packages described in previous chapters.
2.
From the primary database, create a control file for the standby database and then shutdown the
primary database.
% svrmgrl
SVRMGR>connect internal
SVRMGR>alter database create standby controlfile as /tmp/control01.ctl;
SVRMGR>shutdown
SVRMGR>exit
%
43
Place the standby control file that you created above into the following two directories on the
standby host: /data/oradata/GMS and /export/apps/oracle/admin/GMS/multiplex/control.
6.
Configure the standby database to automatically apply the archived redo logs to be received from
the primary database. As user oracle on the standby host, place the standby package standby.tar
that you are given in the Oracle home directory /export/home/oracle, extract the tar file, and then
run the setup script for the standby database.
%
%
%
%
44
cd /export/home/oracle
tar xvf standby.tar
cd stdby_config/scripts/setup
./setupstandby.ksh
Start the standby database listener, mount the database as standby, and then place it in managed
recovery mode. As user oracle on the standby host:
% lsnrctl start listener_standby_gms
% svrmgrl
SVRMGR>connect internal
SVRMGR>startup nomount
SVRMGR>alter database mount standby database;
SVRMGR>recover managed standby database
8.
On the primary host, configure the primary database to automatically archive the redo logs to the
standby database. As user oracle, place the standby package standby.tar that you are given in the
Oracle home directory /export/home/oracle, extract the tar file, and then run the setup script for the
primary database.
%
%
%
%
9.
After you execute the above command, the SVRMGR prompt does not return and stay on
the next line. This is normal. Do not press CTRL+C. Pressing CTRL+C will cancel the
managed recovery, and the logs from the primary database will not be applied. Closing the
terminal window does not affect the managed recovery; the recovery continues in the
background.
cd /export/home/oracle
tar xvf standby.tar
cd stdby_config/scripts/setup
./setupprimary.ksh
Start the primary database, its listener, and all NMS processes. Refer to the Software Installation
Setup Guide provided with your SYMMETRY NMS system for the correct steps.
This completes the setup steps for both the primary and the standby database. When it is time to
archive a redo log file on the primary database, it will also be archived and applied to the standby
database.
45
6.4
6.4.1
46
6.4.2
If the archiving of redo logs from the primary to the standby databases is working properly, the value
you get from both the primary and standby databases should match.
6.4.3
47
6.4.4
2.
Identify the gaps by running the script gap.ksh on the standby host.
% cd /export/home/oracle/stdby_config/scripts/utils
% ./gap.ksh
If there is no gap, then the script should return either no result, or the LowSeq# will be equal to the
HighSeq#.
48
Using FTP or making a CD, transfer the archived log files from seq# 460 to seq# 463 in
/data/oradata/GMS/archive on the primary host to the standby host and place them in both of the
following directories: /data/oradata/GMS/archive and
/export/apps/oracle/admin/GMS/multiplex/archives.
f
4.
You must place these log files in both directories, otherwise the step below will fail and you
will receive error messages about not finding a log file in the directory.
On the standby host, cancel the managed recovery that is still in progress and then apply the log
files within the gap sequences.
% svrmgrl
SVRMGR> recover managed standby database cancel
SVRMGR> recover automatic standby database
5.
After recovering the available logs, Oracle prompts for the name of a log that does not exist. The
reason is that the recovery process does not know about the logs archived to the standby site by
the primary database. For example, you might see:
ORA-00308: cannot open archived log /oracle/standby/standby_logs/arcr_1_464.arc
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
49
7.
You are now ready to put the managed recovery mode back on.
SVRMGR> recover managed standby database
The standby database will now again be able to automatically apply the archived logs to be received
from the primary database.
50
6.5
2.
3.
Now you can start SQL*Plus sessions on the standby host the same way you do on the primary
host, and perform SQL select commands against any Gabriel, Raphael, and MOM tables.
You should put the standby database back to managed recovery mode as soon as you have completed
your queries.
51
Make sure that you exit all SQL*Plus sessions that you opened during the read-only mode.
2.
If you have not caused a gap sequence while the database was in read-only mode, the managed
recovery will continue when a new log file is received from the primary database. If there is any gap
sequence, you must resolve the gap; refer to Section 6.4.4 Resolving a Gap Sequence on
page 48.
52
6.6
6.6.1
Cancel the ongoing managed recovery, activate the standby, and then shut down all standby
database background processes. As user oracle on the standby host:
% lsnrctl stop listener_standby_gms
% svrmgrl
SVRMGR> connect internal
SVRMGR> recover managed standby database cancel
SVRMGR> alter database activate standby database;
If you receive an error message from the above command, please stop here and follow the
steps described in Step 2 on page 54. If not, continue with Step 3 on page 54.
53
You may get error messages when you execute the above alter database activate standby
database command. If you do, please follow these steps to restart the standby database, try the
alter database command again, and then shutdown the standby database, before you proceed to
Step 3 on page 54 for starting up the new primary database:
SVRMGR> shutdown immediate
SVRMGR> exit
% svrmgrl
SVRMGR>connect internal
SVRMGR>startup nomount
SVRMGR>alter database mount standby database;
SVRMGR> alter database activate standby database;
SVRMGR> shutdown immediate
SVRMGR> exit
%
3.
Start the new primary database. As user oracle on the activated standby (the new primary) host
% lsnrctl start listener_gms
% svrmgrl
SVRMGR> connect internal
SVRMGR> startup mount
SVRMGR> alter database open;
SVRMGR> exit
%
You can now proceed to start all NMS background processes on the new primary host. As soon as you
have done this, the new primary NMS systems are ready for use by users.
54
If your Raphael system is standalone (i.e., the Raphael system is running on its own host), you
may also need to run the script gabrielhost_script to configure the new primary database so
that Gabriel will continue to send CDR data to the Raphael system. Please consult the Software
Installation Setup Guide provided with your SYMMETRY NMS system.
6.6.2
On the new primary host, you may need to reinstall all SYMMETRY NMS software, such as Gabriel,
Raphael, MOM, as well as database maintenance packages.
2.
Make a cold backup of the activated standby database (the current primary system).
3.
Restore the cold backup to the original primary database by following the steps in Section 5.1
Restoring the NMS Database from a Cold Backup on page 30.
4.
Shut down the activated standby database and NMS processes on the current primary host.
5.
Start up the restored database on the original primary host and NMS processes.
Users can now access the original primary host as their SYMMETRY NMS systems.
6.
Make a cold backup of the primary database and use the backup to recreate the standby database.
55