jump to navigation

Creating Multiple TNS Aliases using a Response file May 29, 2013

Posted by tamnau in Database, General, Scripts, TNS.
Tags: , , , , , , ,
add a comment

I often here DBAs run into TNS issues rambling on about:

“I can’t believe there was a missing bracket in the TNS entry”

or

“The syntax was incorrect in the TNS”.

Yes I admit, I have been one of those DBAs who has hacked away at the tnsnames.ora and has faced this issue in past.   Although not widely known or used, there are solutions to this issue.

Solution A:
You can use the netca wizard, if you prefer to click away, however you need to ensure that you have X session enabled.

Solution B: (I prefer this option!)
A quicker and easy way of creating multiple entries for TNS is to use the netca response file with silent mode.

You can use the netca response file to create listener(s) as well but in this example, we will concentrate on looking at creating TNS aliases using a response file.  This is not a new feature and has been available in previous versions of Oracle.

1. I want to create the following TNS alias entries for the following:

tns_alias copy

2. Take note of the following parameters

NSN_NUMBER – This is the number TNS alias(es) you want to create
NSN_NAMES – List all the TNS alias(es) names
NSN_SERVICE – List all the TNS service(s) associated with the TNS alias(es)
NSN_PROTOCOLS – List the protocol,host and port for each TNS alias

3. The following response file I will create is called 11203_netca.rsp and I have configured it as below:
##################### 11203_netca.rsp ######################
[GENERAL]
RESPONSEFILE_VERSION="11.2"
CREATE_TYPE="CUSTOM"
[oracle.net.ca]
INSTALL_TYPE=""custom""
NAMING_METHODS={"TNSNAMES","ONAMES","HOSTNAME"}
#--------------- Modify settings in this section ---------------
NSN_NUMBER=2
NSN_NAMES={"GREY","GREY_STBY"}
NSN_SERVICE={"GREY","GREY_STBY"}
NSN_PROTOCOLS={"TCP;lnx161;1521","TCP;lnx162;1521"}
#---------------------------------------------------------------
#######################################################

4. Now execute the netca utility in silent mode using the response file (eg. 11203_netca.rsp)
oracle@lnx161:[GREY]$ netca /silent /responseFile /home/oracle/11203_netca.rsp

Output:

Parsing command line arguments:
Parameter "silent" = true
Parameter "responsefile" = /home/oracle/11203_netca.rsp
Done parsing command line arguments.
Oracle Net Services Configuration:
Warning: Oracle Restart is not running.
Listener configuration will not be registered/unregistered with Oracle Restart.
Default local naming configuration complete.
Created net service name: GREY
Default local naming configuration complete.
Created net service name: GREY_STBY
Profile configuration complete.
Oracle Net Services configuration successful. The exit code is 0

5. Verify that the TNS aliases GREY and GREY_STBY is now created in tnsnames.ora:

oracle@lnx161:[GREY]$ cat $TNS_ADMIN/tnsnames.ora

Output:

# tnsnames.ora Network Configuration File: /u01/app/oracle/11.2.0.3/db/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
 
GREY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnx161)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = GREY)
    )
  )
 
GREY_STBY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = lnx162)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = GREY_STBY)
    )
  )

6. Perform a tnsping for each TNS alias, to confirm entry is working.

a) TNS alias – GREY 

oracle@lnx161:[GREY]$ tnsping GREY

Output:

TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 29-MAY-2013 11:13:30
 
Copyright (c) 1997, 2011, Oracle. All rights reserved.
 
Used parameter files:
/u01/app/oracle/11.2.0.3/db/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = lnx161)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = GREY)))
OK (0 msec)

a) TNS alias – GREY_STBY

oracle@lnx161:[GREY]$ tnsping GREY_STBY

Output:

TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 29-MAY-2013 11:14:21
 
Copyright (c) 1997, 2011, Oracle. All rights reserved.
 
Used parameter files:
/u01/app/oracle/11.2.0.3/db/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = lnx162)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = GREY_STBY)))
OK (0 msec)

7. This now completes the TNS alias configuration.

Advertisements

Oracle Backup and Recovery for a VLDB (Very Large Database) February 10, 2011

Posted by tamnau in Database, General, RMAN.
Tags: , , , , , , , , , , , , ,
4 comments

There is an ongoing focus for businesses to minimise downtime and increase operational continuity.  With such challenges, IT staff are constantly under pressure to meet such demands.   For DBAs, backup and recovery is one of the key areas which can be reviewed to ensure that a faster approach to recovery can be achieved to reduce downtime.

An RMAN feature called Incremental Merge (also referred to as Incremental Updated)  Backups can significantly reduce recovery time if configured correctly.  Perhaps not as widely used but has been around since 10g,  it is the ideal backup methodology for a VLDB (Very Large Database).  How it works is that the image copies of the data files are created and  incrementals are then applied rolling forward the image copies after each backup operation.   It is also important to enable fast incremental backups with BCT (Block Change Tracking). For more detailed information on BCT, please refer to the Pythian Whitepaper written by Alexander Gorbachev.

The table below lists the configuration that will be used for the following demonstration:

Description Value
Database Instance ORACLE_SID=VLDB
Host lnx01.earth.com
RMAN Catalog DB (TNS Name) RMANCAT
RMAN Catalog User rman


SECTION 1 – CONFIGURE BLOCK CHANGE TRACKING

1. To create block change tracking file, run the command in sqlplus as sysdba:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '<path_to_block_change_file_name>';

For example:
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/u02/oradata/VLDB/bct_VLDB.ctf';

IMPORTANT NOTE: If running in a RAC configuration, the following file needs to be placed on the cluster shared file system.

2. Login to database and verify the location of data files.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u02/oradata/VLDB/o1_mf_system_7o8kj2gt_.dbf
2 /u02/oradata/VLDB/o1_mf_sysux_2o3mt9jl_.dbf
3 /u02/oradata/VLDB/o1_mf_undotbs_1c5gb8nh_.dbf
4 /u02/oradata/VLDB/o1_mf_users_5v5db3vv_.dbf


SECTION 2 – CONFIGURE RMAN PARAMETERS

1. Register database with RMAN Catalog if using Catalog mode. See example here.

2. Connect to RMAN in catalog (or no catalog) mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] rman target / catalog rman/@RMANCAT

3. Configure the preferred RMAN Recovery Window. In the example, the recovery window will be 3 days.
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

4. It is also recommended that you enable autobackup of controlfile in RMAN.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

SECTION 3 – Performing the Incremental Merge (Updated) Backup

1. Perform the backup of the database in RMAN, and this will create an image copy on the initial run otherwise it will apply the incrementals and rolls forward the image copies of data files.
RMAN> run
{
sql 'alter system archive log current';
recover device type disk
copy of database with tag 'MIB_UPDATE';
backup incremental level 1
for recover of copy with tag 'MIB_UPDATE' database;
sql 'alter system archive log current';
}
list copy of database tag 'MIB_UPDATE';
list backup tag 'MIB_UPDATE';

2. Repeat the previous step for any future or subsequent backups.

SECTION 4 – Performing the Recovery from Incremental Merge (Updated) Backup

An unexpected outage has occurred and now a recovery is required to be performed to bring the database back up quickly as possible.

1. To perform the database recovery ensure that the database in MOUNT mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> shutdown abort
SQL> startup mount

2. In RMAN, switch database to use image copy and then perform recovery.
RMAN> set echo on;
switch database to copy;
run {
recover database;
alter database open;
}

3. Login to database and verify the location of data files are pointing to the recovered image copies.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u03/orafra/VLDB/datafile/o1_mf_system_6o7mj1gt_.dbf
2 /u03/orafra/VLDB/datafile/o1_mf_sysaux_6o7mj4j9_.dbf
3 /u03/orafra/VLDB/datafile/o1_mf_undotbs1_6o7ml4yx_.dbf
4 /u03/orafra/VLDB/datafile/o1_mf_users_6o7mlhl4_.dbf

SECTION 5 – Switching database files back to original data file location

As the database is continuing to run from where the recovered image copies are located, there may be a desire to restore it back to its original location. This is optional, however it is recommended if you are running image copies from FRA (Fast Recovery Area).

1. Backup the database in RMAN
RMAN> run
{
ALLOCATE CHANNEL d1 TYPE DISK FORMAT '/u02/oradata/VLDB/%U.dbf';
recover
copy of database with tag 'MIB_RELOCATE';
backup incremental level 1
for recover of copy with tag 'MIB_RELOCATE' database;
release channel d1;
}
list copy of database tag 'MIB_RELOCATE';
list backup tag 'MIB_RELOCATE';

NOTE: If this is the first time of running the backup to new location, it will create the image copies of the datafiles.

2. Repeat the previous step for any future or subsequent backups until a time can be scheduled to switch back.

3. When a planned time has been scheduled and switch back can be performed, shutdown database and startup in MOUNT mode.
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup mount

4. Switch database to use image copy and then perform recovery.  The database will now be started using image copies which is now configure in the original data file location.
RMAN> set echo on;
switch database to copy;
run {
recover database;
alter database open;
}

5. Login to database and verify the data files are pointing to the recovered image copies back in the original location (or directory).
[oracle@lnx01] export ORACLE_SID=VLDB; . oraenv
[oracle@lnx01] sqlplus / as sysdba
SQL> col file_name form a75
SQL> select file_id, file_name from dba_data_files
/
FILE_ID FILE_NAME
---------- --------------------------------------------------
1 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-SYSTEM_FNO-1_cim4edhc.dbf
2 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-SYSAUX_FNO-2_cjm4edig.dbf
3 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-UNDOTBS1_FNO-3_ckm4edjj.dbf
4 /u02/oradata/VLDB/data_D-VLDB_I-2643384069_TS-USERS_FNO-4_clm4edk2.dbf

CONSIDERATIONS
In conclusion, it is worth noting that when using RMAN Incremental Merge (Updated) Backup strategy, it is important to consider the following:

  • More storage is required to store the copy of database in addition to the traditional incremental backups.
  • For Point-In-Time recovery, continue to at least perform one full backup of database and include archive logs.  This can be can be performed less frequently (ie weekly, fortnightly, monthly).
  • Validate image copies and backups to detect if there is corruption or missing files which may compromise recovery.
  • Image copies of database should be on same storage tier as online data files to ensure performance it is not impacted when switching to database copy for recovery.
  • Image copies do not have to be stored in FRA, but should be stored on disk.