npm security guide

Corporate HeadquartersRedback Networks Inc.100 Headquarters DriveSan Jose, CA 95134-1362USAhttp://www.redback.comTel: +1 408 750 5000

NetOp Policy ManagerDatabase Troubleshooting Guide

Release 6.1.5Part Number 4/1543-CRA 119 1030/1 Uen A

© 1996 to 2008, Ericsson AB. All rights reserved.

Redback and SmartEdge are trademarks registered at the U.S. Patent & Trademark Office and in other countries. AOS, NetOp, SMS, and User Intelligent Networks are trademarks or service marks of Redback Networks Inc. All other products or services mentioned are the trademarks, service marks, registered trademarks or registered service marks of their respective owners. All rights in copyright are reserved to the copyright owner. Company and product names are trademarks or registered trademarks of their respective owners. Neither the name of any third party software developer nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission of such third party.

Rights and RestrictionsAll statements, specifications, recommendations, and technical information contained are current or planned as of the date of publication of this document. They are reliable as of the time of this writing and are presented without warranty of any kind, expressed or implied. In an effort to continuously improve the product and add features, Redback Networks Inc. (“Redback”) or Ericsson AB (“Ericsson”) reserves the right to change any specifications contained in this document without prior notice of any kind.

Neither Redback or Ericsson nor its parent or affiliate companies shall be liable for technical or editorial errors or omissions which may occur in this document. Neither Redback or Ericsson nor its affiliate companies shall be liable for any indirect, special, incidental or consequential damages resulting from the furnishing, performance, or use of this document.

DisclaimerNo part of this document may be reproduced in any form without the written permission of the copyright owner.

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Redback or Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Contents iii

Contents

Chapter 1: NetOp Database Troubleshooting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1NetOp Database Directory Path Substitutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Chapter 2: NetOp Database Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Verify That the Primary and Standby Databases Are Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Determine the Name and Status of a Current Fast-Start Failover Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Determine the Status of the Standby Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Determine the Latest Primary and Standby Redo Log Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5View the Oracle Data Guard Broker Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Chapter 3: NetOp Database Failover Configuration Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Verify That the Observer Process on a Solaris Host Is Operational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Verify That the Observer Process on a PC Host Is Operational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Move the Observer Process to Another Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Stop and Restart the Observer Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Errors Connecting to the Standby Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3View the Oracle Alert Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Convert Manual Failover to Fast-Start Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Check the Status of the NetOp Databases in Fast-Start Failover Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Disable Fast-Start Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

Chapter 4: NetOp Database Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Monitor the NetOp Database and Generate E-Mail Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Troubleshoot the NetOp Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Generate the NetOp Database Performance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Tune the NetOp Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

iv NetOp Policy Manager Database Troubleshooting Guide

NetOp Database Troubleshooting Overview 1-1

C h a p t e r 1

NetOp Database Troubleshooting Overview

This guide contains troubleshooting information and solutions for the NetOp Policy Manager (PM) database. Use this guide to look up information and recommended actions in response to database configuration problems, and performance issues.

NetOp Database Directory Path Substitutions

Use Table 1-1 to identify the correct directory path substitution when instructed to navigate to the various directories in the procedures in this guide.

Table 1-1 Directory Paths to NetOp™ Database Scripts

Directory Path Substitution Path to Database Script Directories

Administration /usr/local/npm/admin

Maintenance /usr/local/npm/maintenance

Diagnostic /usr/local/npm/diagnostic

Installation /usr/local/npm

NetOp Database Directory Path Substitutions

1-2 NetOp Policy Manager Database Troubleshooting Guide

NetOp Database Issues 2-1

C h a p t e r 2

NetOp Database Issues

This chapter provides techniques for troubleshooting problems with your NetOp™ high-availability database configuration and includes the following topics:

• Verify That the Primary and Standby Databases Are Running

• Determine the Name and Status of a Current Fast-Start Failover Database

• Determine the Status of the Standby Database

• Determine the Latest Primary and Standby Redo Log Numbers

• View the Oracle Data Guard Broker Log File

Verify That the Primary and Standby Databases Are Running

The verify_npm_standby.sh script verifies that the primary and standby NetOp databases are operating properly. The script sends information from the primary database to the standby database and then checks the status of the changes. Because the time required by this transmission varies depending on network traffic and database host loads, use the -time_delay minutes_to_wait construct to configure the interval between transmitting data from the primary database and checking the status of the changed data on the standby database.

If you are planning to run this script after running the setup_primary_db.sh script, wait at least five minutes before you run the verify_npm_standby.sh script to allow for all processing to be completed on the primary database host.

To verify that both the primary and standby NetOp databases are working properly:

1. Log on to the standby NetOp database host as oracle and open a terminal window.

2. Navigate to the Administration directory.

Caution Risk that the verify_npm_standby.sh script fails following a failover. After a failover, the database on the failed database host is not operational. If you run the verify_npm_standby.sh script from the failed primary database host while it is not operational, it fails. To avoid this risk, fix the problem that caused the failover and restore the failed primary database as the standby database before you try to run the script on this host.

Determine the Name and Status of a Current Fast-Start Failover Database


3. Run the verify_npm_standby.sh script with the following syntax:

verify_npm_standby.sh [-db database_name] [-h] -sys_passwd system_account_password [-time_delay minutes_to_wait]

The script takes as much time to run as the value of the -time_delay minutes_to_wait construct. You are prompted to enter the password for the primary database. A message is displayed when the script terminates to indicate whether the standby database is working properly.

Table 2-1 describes the syntax and usage guidelines for this script.

If the standby NetOp database is not working, view the standby NetOp database Oracle Data Guard Broker log file. For information on viewing these log files, see the “View the Oracle Data Guard Broker Log File” section on page 2-5.


To determine the name and status of a fast-start failover database:

1. Log on to the NetOp database on which you want to identify the name and status.

2. Start a DataGuard broker CLI session by entering the following command at the UNIX command line:

dgmgrl

The Data Guard broker CLI appears.

Table 2-1 Syntax for the verify_npm_standby.sh Script

Syntax Description

-db database_name Optional. Name of the NetOp database.

-h Optional. Prints usage information and exits the script.

-sys_passwd system_account_password Password for the database system account.

-time_delay minutes_to_wait Optional. Time to wait (in minutes) before checking for applied data at the standby NetOp database. Valid values are 1 to 15; the default value is 5.

Note If network communication is not optimal, you run the risk of experiencing problems with the standby database. If you experience an unusually high number of issues related to administering the standby database, verify the following:

• Network communication between the primary and standby database is operating optimally.

• Network changes applied to the standby database are not affecting network communication.



3. Enter the following lines in the Data Guard broker CLI:

connect sys/password@database-name;

show configuration

where the value of the password argument is the password of the sys Oracle database account (the default value is redback), and the value of the database-name argument is the database name.

Information similar to the following appears:

---------------------------------------------------------DGMGRL> show configurationConfiguration Name: npmcold_DG Enabled: YES Protection Mode: MaxAvailability Fast-Start Failover: ENABLED Databases: npm - Primary database npm_clone - Physical standby database - Fast-Start Failover target

Current status for "npmcold_DG":SUCCESS

In this example, the output identifies the primary database as npm and the standby database as npm_clone.

Table 2-2 describes the warning and error messages associated with the current status of the fast-start failover configuration.

Table 2-2 Warnings and Error Messages from the show configuration Command

Status Description Action Required

SUCCESS All three fast-start failover components are properly configured and available

None

Warning: ORA-16608: one or more databases have warnings

One or both of the following scenarios:• The DataGuard observer is either

not set up or is not running.• The standby database was

stopped using the stop_npm_db.sh script.

To determine which scenario is in effect, see the “Check the Status of the NetOp Databases in Fast-Start Failover Configuration” section on page 3-5.

If the DataGuard observer is:• Not set up—See Chapter 2, “NetOp Database Failover

Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

• Not started—Restart it with the setup_observer.sh script; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

• If the Standby database is stopped, restart it with the start_npm_db.sh; for more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

Determine the Status of the Standby Database


4. If the status field shows an error, enter the following command to investigate:

show database verbose “database-name”

where the value of the database-name argument is the database name of either the primary database or standby database.

You can also view the Oracle Data Guard Broker log files. If you do not understand an error message, contact your local Redback® technical support representative and provide a copy of the diagnostic tar file and broker log files. For information on viewing Oracle broker log files, see the “View the Oracle Data Guard Broker Log File” section on page 2-5.

Determine the Status of the Standby Database

If the verify_npm_standby.sh script reports that the standby database is not operational:

1. Log on to the primary NetOp database as the Oracle system administrator (for example, sys) using the following command:

sqlplus sys/password@database-name as sysdba

where the value of the password argument is the password of the system database account (the default value is redback), and the value of the database-name argument is the database name.

2. In the SQL*Plus session, enter the following command:

select STATUS from v$archive_dest where DEST_NAME='STANDBY_ARCHIVE_DEST';

3. If the status reported is anything other than valid, record the content of the error column.

4. Exit the SQL*Plus session.

5. On both the primary and standby databases, examine the most recent section of the alert log files to check for errors (for example, see the /u01/app/oracle/product/10g/admin/npm/bdump/alert_npm.log file).

Send the error columns from the status query and the alert_.log files, or the diagnostic tar file to your local Redback technical support representative.

Error: ORA-16625: cannot reach the database

The primary database has:• Been stopped using the

stop_npm_db.sh script.• Failed.To determine which scenario is in effect, see the “Check the Status of the NetOp Databases in Fast-Start Failover Configuration” section on page 3-5.

If the primary database is:• Stopped—Restart it with the start_npm_db.sh; for

more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

• Failed—Recover from the failure; for more information, see Chapter 3, “NetOp Database Failover Management” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Warning: ORA-16607: one or more databases have failed

The standby database has failed. Recover from the failure; for more information, see Chapter 3, “NetOp Database Failover Management” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Table 2-2 Warnings and Error Messages from the show configuration Command (continued)

Status Description Action Required

Determine the Latest Primary and Standby Redo Log Numbers


Determine the Latest Primary and Standby Redo Log Numbers

To determine the latest primary and standby redo log file numbers:

1. Determine the number of the redo log file archived most recently by the primary database:

a. Log on to the primary database host as oracle.

b. Log on to the NetOp database as the Oracle system administrator (for example, sys) using the following command:



c. In the SQL*Plus session, enter the following query:

select max(sequence#) from v$archived_log;

2. Determine the number of the latest redo log file received and the last redo log file processed by the standby database:

a. Log on to the standby database host as oracle.

b. Log on to the NetOp database as the Oracle system administrator (for example, sys) using the following commands:



c. Determine the last redo log file received from the primary database; in the SQL*Plus session, enter the following query:

select max(sequence#) from v$archived_log;

d. Determine the last redo log file processed by the standby database; enter the following query:

select max(sequence#) from v$log_history;

The numbers of these log files should match the numbers on the primary database. If not, consult the Oracle alert log file on the standby database host for errors.

If the log numbers do not match, send the error message and the alert_.log or diagnostic tar file to your local Redback technical support representative.

e. Exit the SQL*Plus session.

View the Oracle Data Guard Broker Log File

If you have a fast-start failover configuration, the Oracle Data Guard Broker records NetOp database behavior and status information in a broker log file.

View the Oracle Data Guard Broker Log File


To view the Oracle database guard broker log file:

1. Log on to the NetOp database host as oracle and open a terminal window.

2. Navigate to the /u01/app/oracle/product/10g/admin/database name/bdump directory.

3. Open the drc_database_name.log file and view the latest error messages at the bottom of the file.

If you do not understand an error message, contact your local Redback technical support representative and provide a copy of your broker log file.

NetOp Database Failover Configuration Issues 3-1

C h a p t e r 3

NetOp Database Failover ConfigurationIssues

This chapter describes procedures to use when you investigate database failover configuration issues. It includes the following topics:

• Verify That the Observer Process on a Solaris Host Is Operational

• Verify That the Observer Process on a PC Host Is Operational

• Move the Observer Process to Another Host

• Stop and Restart the Observer Process

• Errors Connecting to the Standby Database

• View the Oracle Alert Log File

• Convert Manual Failover to Fast-Start Failover

• Check the Status of the NetOp Databases in Fast-Start Failover Configuration

• Disable Fast-Start Failover

Verify That the Observer Process on a Solaris Host Is Operational

To verify that the Data Guard Observer host is operational:

1. Log on to the primary NetOp™ database host as oracle.

2. Log on to the NetOp database as the Oracle user sys using the following command:



3. Enter the following command at the SQL*Plus command line:

select FS_FAILOVER_STATUS, FS_FAILOVER_THRESHOLD, FS_FAILOVER_OBSERVER_PRESENT, FS_FAILOVER_OBSERVER_HOST from v$database;

Table 3-1 describes the information that this query provides for each item specified in the command.

Verify That the Observer Process on a PC Host Is Operational


Verify That the Observer Process on a PC Host Is Operational

To verify that the Data Guard Observer host on a PC is operational:

1. Start a Data Guard broker CLI session by entering the following command at the PC prompt in the command window:

dgmgrl


2. To verify that all components are operational, enter the following line in the Data Guard broker CLI:

show configuration;

If the output shows that the current status for the configuration is anything other than “SUCCESS,” see Table 2-2 on page 2-3.

Move the Observer Process to Another Host

You can move the observer process to another host at any time, including after an unrecoverable crash of the host. You do not need to disable fast-start failover to move the Data Guard Observer host.

To move the observer process to another host:

1. Prepare the new host machine; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

2. Configure and start the observer process on the new host; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

3. Verify that the new observer process is operational; see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Table 3-1 Operational Information About the Observer Process

Query Item Information

FS_FAILOVER_STATUS The current status of the fast-start failover configuration.

FS_FAILOVER_THRESHOLD The length of time the observer process waits before starting fast-start failover.

FS_FAILOVER_OBSERVER_PRESENT One of the following values:• YES• NONote: If the connection to the observer process is lost, the value for FS_FAILOVER_OBSERVER_PRESENT is NO.

FS_FAILOVER_OBSERVER_HOST Hostname of the Data Guard observer host.

Stop and Restart the Observer Process


Stop and Restart the Observer Process

When you restart the observer process, you must first stop the observer process to close the connections established between the previous observer process and DataGuard broker on the primary and standby database hosts.

You can use two methods to stop and restart the observer process:

• Script method—This is the preferred method because the script’s error handling logic. Run the setup_observer.sh script to restart the observer process; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

• DataGuard broker CLI method:

1. Log on to a fast-start failover component host as the oracle user.


dgmgrl


3. Enter the following lines in the Data Guard broker CLI:



stop observer;

start observer;

4. To verify that all components are operational, enter the following line in the DataGuard broker CLI:

show configuration;

If the output shows that the current status for the configuration is anything other than “SUCCESS” see Table 2-2 on page 2-3.

Errors Connecting to the Standby Database

When the Data Guard broker cannot connect to the standby database, you may see the following error message from the Oracle DBMS:

Error: ORA-16796: one or more properties could not be imported from the database

Take the following steps to resolve the error:

• Ensure that you edited the Oracle Net configuration file, listener.ora, on the standby database host; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

View the Oracle Alert Log File


• Ensure that the database has been started on the standby database host.

View the Oracle Alert Log File

To view the Oracle alert log file:

1. Log on to the NetOp database host as oracle and open a terminal window.

2. Navigate to the /u01/app/oracle/product/10g/admin/database name/bdump directory.

3. Open the alert_database_name.log file and view the latest error messages at the bottom of the file.

If you do not understand an error message, contact your local Redback® technical support representative.

Convert Manual Failover to Fast-Start Failover

If you have set up a manual failover configuration, you have the option to convert to fast-start failover by running the enable_fast_start_failover.sh script. In this configuration, make sure that both the primary and standby databases are configured with the same database name or Oracle system identifier (SID) so that client applications are not required to change their references to the database following a failover. The enable_fast_start_failover.sh script configures the:

• Primary NetOp database for fast-start failover

• Standby NetOp database for fast-start failover

• Data Guard broker on the primary NetOp database

You do not need to run the enable_fast_start_failover.sh script if you have already run the setup_primary_db.sh script with the -enable_fast_start_failover option.

To configure the primary and standby NetOp databases for fast-start failover, perform the following steps:

1. Open a terminal window and log on to the primary NetOp database host as root.

2. Run the enable_fast_start_failover.sh script, using the following syntax:

enable_fast_start_failover.sh [-db database_name] [-h] [standby_db_acct standby_database_account_name] -standby_db_passwd standby_database_account_password


Note After you set up the fast-start failover configuration, do not use the scripts provided for switching databases in a manual failover configuration. You must use the DataGuard broker CLI instead.

Table 3-2 Syntax for the enable_fast_start_failover.sh Script

Syntax Description


-h Optional. Prints usage information and exits.

Check the Status of the NetOp Databases in Fast-Start Failover Configuration



After you have reviewed the status of fast-start failover configuration and discovered problems with either the primary or standby database, you can use the show database command of the DataGuard broker CLI to gather additional information:

1. Log on to either the primary or standby NetOp database host as oracle.


dgmgrl


3. Connect to the database whose status you want to determine:


where the value of the password argument is the password of the sys Oracle database account (the default value is redback) and the value of the database-name argument is the database name.

4. Request the status of the database:

show database database-name

where the value of the database-name argument is the database name.

Table 3-3 describes the warning and error messages associated with the current status of the fast-start failover configuration.

-standby_db_acct standby_database_account_name

Optional. Account name for the standby database sysdba. The default value is sys.

-standby_db_passwd standby_database_account_password

Password for the standby database sysdba account.

Table 3-3 Warnings and Error Messages from the show database Command

StatusConnected to Database Description Action Required

SUCCESS Either All three fast-start failover components are properly configured and available.

None

Table 3-2 Syntax for the enable_fast_start_failover.sh Script (continued)

Syntax Description



Warning: ORA-16819: Fast-Start Failover observer not started

Either The DataGuard observer is either not set up or is not running.

If the DataGuard observer is:• Not set up—See Chapter 2, “NetOp

Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

• Not started—Restart it with the setup_observer.sh script; for more information, see Chapter 2, “NetOp Database Failover Configuration” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Error: ORA-16625: cannot reach the database

Primary The primary database has:• Been stopped using the

stop_npm_db.sh script.

• Failed.

If the primary database is:• Stopped—Restart it with the

start_npm_db.sh; for more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

• Failed—Recover from the failure; for more information, see Chapter 3, “NetOp Database Failover Management” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Warning: ORA-16817: unsynchronized Fast-Start Failover configuration

Primary The standby database was stopped using the stop_npm_db.sh script.

Restart the standby database with the start_npm_db.sh; for more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

Standby The primary database has failed.

Recover from the failure; for more information, see Chapter 3, “NetOp Database Failover Management” in the NetOp Policy Manager Database Redundancy and Recovery Guide.

Error: ORA-16825: Fast-Start Failover and other errors or warnings detected for the database

Primary The standby database has failed.


Warning: ORA-16818: Fast-Start Failover suspended

Standby The primary database has been stopped using the stop_npm_db.sh script.

Restart the primary database with the start_npm_db.sh; for more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

SHUTDOWN Standby The standby database was stopped using the stop_npm_db.sh script.

Restart the standby database with the start_npm_db.sh; for more information, see the “Start and Stop the NetOp Database” section on page 2-3 of the NetOp Policy Manager Database Administration Guide.

Table 3-3 Warnings and Error Messages from the show database Command (continued)


Disable Fast-Start Failover



When a network outage isolates the primary database host from both the Data Guard Observer host and standby database host while the databases are synchronized, the primary database may stall to prevent any further transactions from being committed because a fast-start failover may have occurred while it was isolated. If you expect the network to be disconnected for a long time, disable fast-start failover on the primary database to allow processing to continue (without waiting for the connection to the target standby database or the observer computer to be restored).

Disable fast-start failover on the primary database host only under the following circumstances:

• During a prolonged network outage when all the following conditions apply:

— A prolonged network outage has isolated all three of the following hosts from one another: the primary database host, standby database host, and observer host. In this case, the primary database stalls, preventing new transactions from being committed, and the standby database is unable to fail over to the primary role.

— You expect the network outage to continue.

— You want processing on the primary database to continue without waiting for any of the network connections to be restored.

• When you want to manually fail over to the standby database under either of the following conditions:

— The primary database is no longer synchronized with the standby database.

— The observer process is not running or is not communicating with the standby database.

To disable the fast-start configuration on the primary database host:

1. Log on to the primary NetOp database host as oracle.

2. Start a DataGuard Broker CLI session by entering the following command at the UNIX command line:

dgmgrl


3. Enter the following command to connect to the primary database:



Error: ORA-01034: ORACLE not availableOrError: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

Standby The standby database has failed.


Table 3-3 Warnings and Error Messages from the show database Command (continued)




4. Enter the following command to disable the fast-start configuration:

disable fast_start failover;

In an emergency situation in which you run the disable fast_start failover command and it fails to disable the fast-start failover function, you can use the force option by running the following command:

disable fast_start failover force;

Caution Risk of both database hosts assuming the primary role, resulting in two divergent primary databases. After you disable fast-start failover on the primary host during a network outage, if the connection between the standby database host and the observer host is restored first, the standby host transitions to the primary role. This results in both databases assuming the primary role. To avoid this risk, remove the connection between the standby database host and observer host until the network outage is resolved and the connection between primary database host and observer host is restored.

NetOp Database Performance Issues 4-1

C h a p t e r 4

NetOp Database Performance Issues

This chapter describes how to determine if the NetOp™ database is limiting traffic flow, and provides instructions on how to run the scripts to monitor and troubleshoot the NetOp database in the following sections:

• Monitor the NetOp Database and Generate E-Mail Alerts

• Troubleshoot the NetOp Database

• Generate the NetOp Database Performance Report

• Tune the NetOp Database

Monitor the NetOp Database and Generate E-Mail Alerts

Use the monitor_npm_db.sh script to monitor the NetOp database and generate e-mail alerts if the specified threshold for tablespace usage is reached. When a threshold is reached an alert is generated, and the script sends an e-mail alert to the specified e-mail address. The script also checks Oracle trace files and alert log for errors. If errors are found, the NetOp system sends an alert e-mail to the administrator. Schedule the monitor_npm_db.sh script to run regularly: weekly at least.

To monitor the NetOp database and generate e-mail alerts:

1. Log on to the active database host as oracle and open a terminal window.

2. Navigate to the Diagnostic directory:

3. Run the monitor_npm_db.sh script according to the following syntax:

./monitor_npm_db.sh [-db database_name] [-db_passwd database_account_password] [-email email_address] [-h] [-table_usage tablespace_usage]


Note For the monitor_npm_db.sh script to send e-mail to a nonlocal e-mail address (an e-mail account that is not on the NetOp database), you must ensure that the host’s e-mail configuration is correct. One common issue is that the default Solaris installation requires the hostname, mailhost, to exist on the local network domain, either in the /etc/hosts file or in Domain Name System (DNS) or Network Information Service (NIS), and so on. For example, if your database hostname is dbhost.lab.mycompany.com, there must be a definition for the mailhost.lab.mycompany.com hostname that refers to a valid mail server.

Troubleshoot the NetOp Database


Troubleshoot the NetOp Database

Use the report_npm_db_operations.sh script to collect information about the NetOp database for troubleshooting purposes. Run it when the NetOp database fails or appears to be malfunctioning. The script reports on various OS and database information. The script output should be analyzed by an Oracle database administrator (DBA).

To troubleshoot the NetOp database:

1. Log on to the active database host as oracle and open a terminal window.


3. Run the report_npm_db_operations.shscript according to the following syntax:

./report_npm_db_operations.sh [-db database_name] [-h]


Generate the NetOp Database Performance Report

The report_npm_db_performance.sh script monitors the general performance of the NetOp database and advises how to resolve some database issues. Run it regularly. An Oracle DBA should analyze the output of this script.

To generate a report of the NetOp database performance, perform the following steps:

1. Log on as oracle and open a terminal window.


Table 4-1 Syntax for the monitor_npm_db.sh Script

Syntax Description


-db_passwd database_account_password Optional. NetOp database account password.

-email email_address Optional. E-mail address of the administrator to which alerts are sent. Defined when you run the config_db.sh script. The default value is oracle.


-table_usage tablespace_usage Optional. Tablespace full threshold in percentage form. When the threshold is reached, an alert is generated. Defined when you run the config_db.sh script. The default value is 80.

Table 4-2 Syntax for the report_npm_db_operations.sh Script

Syntax Description



Tune the NetOp Database

NetOp Database Performance Issues 4-3

3. Run the report_npm_db_performance.sh script according to the following syntax:

./report_npm_db_performance.sh [-db database_name] [-db_passwd database_account_password] [-h]



When you install a NetOp PM database, the tune_npm_db.sh script is automatically scheduled to run according to a default task schedule. For more information, see the “Maintain Optimal NetOp PM Database Performance” section on page 3-5 of the NetOp Policy Manager Database Administration Guide.

Run the tune_npm_db.sh script regularly to improve database performance. Because this script affects performance, run it when the system is not busy.

To tune the NetOp database:

1. Log on as oracle and open a terminal window.

2. Navigate to the Maintenance directory.

3. Run the tune_npm_db.shscript according to the following syntax:

./tune_npm_db.sh [-db database_name] [-db_acct database_account_name] [-db_passwd database_account_password] [-h]


Table 4-3 Syntax for the report_npm_db_performance.sh Script

Syntax Description




Table 4-4 Syntax for the tune_npm_db.sh Script

Syntax Description


-db_acct database_account_name Optional. Name of the NetOp database account.



npm security guide

Documents