azad's Blog

Oracle 11g New Features

syedazad — Wed, 08 Jul 2009 11:49:44 +0000

Oracle 11g top features are as follows :

1. Database Replay

2. Flashback Data Archive

3. Automatic Diagnostic Repository – ADR

4. Automatic Memory Tuning
5. Case sensitive password
6. Virtual columns and indexes
7. Interval Partition and System Partition
8. The Query Result Cache
9. ADDM RAC Enhancements
10. SQL Plan Management and SQL Plan Baselines
11. SQL Access Advisor & Partition Advisor
12. SQL Query Repair Advisor
13. SQL Performance Analyzer (SPA)
14. DBMS_STATS Enhancements
15. The PL/SQL Result Cache

1. Database Reply:

This allows the total database workload to be captured, transferred to a test database create from a backup or standby database, then replayed to test the affects of an upgrade or system change. Currently, these are working to a capture performance overhead of 5%, so this will capture real production workloads

The new Database Replay tool works like a DVR inside the database. Using a unique approach, it faithfully captures all database activity beneath the level of SQL in a binary format and then replays it either in the same database or in a different one (which is exactly what you would want to do prior to making a database change). You can also customize the capture process to include certain types of activity, or perhaps exclude some.

Database Replay delivers half of what Oracle calls Oracle Database 11g\’s \”Real Application Testing\” option; the other half is provided by another tool, SQL Performance Analyzer. The main difference between these two tools is the scope involved: whereas Database Replay applies to the capture and replay of all (subject to some filtering) activities in a database, SQL Performance Analyzer allows you to capture specific SQL statements and replay them. (You can\’t see or access specific SQLs captured in Database Replay, while in SQL Performance Analyzer you can.) The latter offers a significant advantage for SQL tuning because you can tweak the SQL statement issued by an application and assess its impact. (SQL Performance Analyzer is covered in a forthcoming installment in this series.)

2. Flashback Data Archive /Total Recall
A new database object, a flashback data archive is a logical container for storing historical information. It is stored in one or more tablespaces and tracks the history for one or more tables.

You specify retention duration for each flashback data archive (could be # of years).

SQL> create flashback archive fla1 tablespace tbs1 retention 2 year;

With the \”Oracle Total Recall\” option, Oracle database 11g has been specifically enhanced to track history with minimal performance impact and to store historical data in compressed form to minimize storage requirements, completely transparent to applications, easy to setup . This efficiency cannot be duplicated by your own triggers, which also cost time and effort to set up and maintain.

To satisfy long-retention requirements that exceed the undo retention, create a flashback data archive

3. ADR – Automatic Diagnostics Repository

All trace files, core files, and the alert files are now organized into a directory structure comprising the Automatic Diagnostic Repository (ADR).

The ADR is a file-based repository for database diagnostic data. It has a unified directory structure across multiple instances and multiple products.
Beginning with Release 11g, the database, Automatic Storage Management (ASM), Cluster Ready Services (CRS), and other Oracle products or components store all diagnostic data in the ADR. Each instance of each product stores diagnostic data underneath its own ADR home directory.

For example, in an Oracle Real Application Clusters environment with shared storage and ASM, each database instance and each ASM instance has a home directory within the ADR. ADR\’s unified directory structure, consistent diagnostic data formats across products and instances, and a unified set of tools enable customers and Oracle Support to correlate and analyze diagnostic data across multiple instances.

The location of the ADR is controlled by the Oracle \”diagnostic_dest\” parameter.
Path specified in the \’diagnostic_dest\’ parameter defines the ADR root directory,ADR BASE.

The first subdirectory inside an ADR (under the directory) is always named \”diag\”

For example, if the \’diagnostic_dest\’ and thus the is specified as \”$ORACLE_HOME/log\”, then expect to find the subdirectory \”$ORACLE_HOME/log/diag\”. Below this will be .
Any number of instances/components can share same ADR BASE. Under ADR BASE there will be individual ADR HOMES.
Under ADR BASE ,the address of an will be similar to :
diag///.

Inside each ADR home, you can find several subdirectories, each for storing a specific type of diagnostic data. Among the subdirectories, you should be able to find TRACE, ALERT, INCIDENT, CDUMP etc

4. Automatic Memory Tuning

Automatic PGA tuning was introduced in Oracle 9i. Automatic SGA tuning was already
introduced in Oracle 10g. But In 11g, all memory can be tuned automatically by setting one parameter. We can literally tell Oracle how much memory it has and it determines how much to use for PGA, SGA and OS Processes. Maximum and minimum thresholds can be set.

Automatic Memory Management is being introduced in 11g. This enables automatic tuning of PGA and SGA with use of two new parameters named MEMORY_MAX_TARGET and MEMORY_TARGET.

You have to use RESULT_CACHE_MODE initialization parameter which determines the SQL query result cache behavior. The possible initialization parameter values are MANUAL and FORCE

RESULT_CACHE_MAX_SIZE is new component which has been introduced as part of 11g Memory architecture. The result cache is composed of the SQL query result cache and PL/SQL function result cache, which share the same infrastructure. Results of queries and query fragments can be cached in memory in the SQL query result cache. The database can then use cached results to answer future executions of these queries and query fragments. Similarly PL/SQL Function Result can also be cached.

5.Case sensitive password :

Passwords are expected to also become case sensitive This and other changes should result in better protection against password guessing scenarios. For example, in addition to limiting the number of failed login attempts to 10 (default configuration in 10gR2), Oracle 11g beta’s planned default settings should expire passwords every 180 days, and limit to seven the number of times a user can login with an expired password before disabling access.

6.Virtual columns/indexes :

User can create Virtual index on table. This Virtual index is not visible to optimizer, so it will not affect performance, Developer can user HINT and see is Index is useful or not.Invisible Indexes prevent premature use of newly created indexes

When queried, virtual columns appear to be normal table columns, but their values are derived rather than being stored on disc. The syntax for defining a virtual column is listed below.

column_name [datatype] [GENERATED ALWAYS] AS (expression) [VIRTUAL]
If the datatype is omitted, it is determined based on the result of the expression. The GENERATED ALWAYS and VIRTUAL keywords are provided for clarity only.

A virtual index is created in a slightly different manner than the normal indexes. A virtual index has no segment pegged to it, i.e., the DBA_SEGMENTS view will not show an entry for this. Oracle handles such indexes internally and few required dictionary tables are updated so that the optimizer can be made aware of its presence and generate an execution plan considering such indexes.

7. Interval Partition and System Partition

Interval partitioning is an extension of range partitioning, where the system is able to create new partitions as they are required. The PARTITION BY RANGE clause is used in the normal way to identify the transition point for the partition, then the new INTERVAL clause used to calculate the range for new partitions when the values go beyond the existing transition point.

The following code shows an example of a table using interval partitioning.

CREATE TABLE interval_PART (

EMPid NUMBER,

DEPTcode VARCHAR2(10),

INTERVAL_descr VARCHAR2(50),

created DATE

)

PARTITION BY RANGE (created)

INTERVAL (NUMTOYMINTERVAL(1,’MONTH’))

(

PARTITION part_01 values LESS THAN (TO_DATE(‘01-NOV-2007’,’DD-MON-YYYY’))

);

System Partition

System partitioning allows large tables to be broken down into smaller partitions, but unlike other partitioning schemes, the database has no control over the placement of rows during insert operations. The following example shows the creation of a system partitioned table.

CREATE TABLE part_system (

empid NUMBER,

deptcode VARCHAR2(10),

description VARCHAR2(50),

created DATE

)

PARTITION BY SYSTEM

(

PARTITION part_1,

PARTITION part_2

);

8. Query Result Cache

A separate shared memory pool is now used for storing and retrieving cached results. Query retrieval from the query result cache is faster than rerunning the query. Frequently executed queries will see performance improvements when using the query result cache.

The new query result cache enables explicit caching of results in database memory. Subsequent queries using the cached results will experience significant performance improvements.

Enable Result Caching :

You can set the RESULT_CACHE_MODE initialization parameter to control whether the SQL query result cache is used for all queries (when possible).

This parameter can be set at the system, session, or table level to the following values:

MANUAL – The results of a query can only be stored in the result cache by using the result_cache hint.
FORCE – All results are stored in the result cache.

Example:
If the RESULT_CACHE_MODE parameter is set to MANUAL then you must explicitly use the /*+ result_cache */ hint in your query to store the results of a query in the result cache.

SELECT /*+ result_cache */ deptno, avg(sal)
FROM emp
GROUP BY deptno;

If the RESULT_CACHE_MODE parameter is set to FORCE, and you do not wish to include the result of the query in the result cache, then you must use the /*+ no_result_cache */ hint in your query.

SELECT /*+ no_result_cache */ deptno, avg(sal)
FROM emp
GROUP BY deptno;

The database automatically invalidates a cached result whenever a transaction modifies the data or metadata of any of the database objects used to construct that cached result.

9. ADDM RAC Enhancements

Oracle Database 11g now offers what it calls database ADDM, or the ability to run ADDM reports at the overall clustered database level as well as at the individual database instance level. Whenever a new Automatic Workload Repository (AWR) snapshot is requested, or whenever an ADDM analysis has been executed against a set of existing AWR snapshots, ADDM first analyzes each individual RAC instance’s performance (aka instance ADDM) and then immediately performs an ADDM database analysis.

10. SQL Plan Management and SQL Plan Baselines

The SQL statement is hard parsed, the cost based optimizer produces several execution plans and selects the one with the lowest cost. If a SQL plan baseline is present, the optimizer tries to find a matching plan in the SQL plan baseline that is flagged as accepted. If a matching plan is found, the optimizer will uses the plan. If the SQL plan baseline doesn\’t contain a matching plan, the optimizer evaluates the accepted plans in the SQL plan baseline and uses the one with the lowest cost. If the execution plan originally produced by the optimizer has a lower cost than those present in the SQL plan baseline, it is added to the baseline as a not-accepted plan, so it is not used until it is verified not to cause a reduction in performance. If a system change affects all existing accepted plans, the optimizer will use the original plan with the lowest cost and mark this as accepted.

Oracle call this a \”conservative plan selection strategy\”, as the optimizer preferentially uses a tried an tested execution plan, even if a new plan looks like it might perform better. Only when the newer plan is proved to perform well will it be accepted for use.

The use of SQL plan baselines is controlled by the OPTIMIZER_USE_SQL_PLAN_BASELINES parameter, which is set to TRUE by default.

SQL Management Base

The SQL management base resides in the SYSAUX tablespace and stores SQL plan baselines, as well as statement logs, plan histories and SQL profiles. Space usage is controlled by altering two name-value attributes using the CONFIGURE procedure of the DBMS_SPM package.

· space_budget_percent (default 10) : Maximum size as a percentage of SYSAUX space. Allowable values 1-50.

· plan_retention_weeks (default 53) : Number of weeks unused plans are retained before being purged. Allowable values 5-523 weeks.

11. SQL Access Advisor & Partition Advisor

SQL Access Advisor was introduced in Oracle 10g to make suggestions about additional indexes and materialized views which might improve system performance. Oracle 11g has made two significant changes to the SQL Access Advisor:

The advisor now includes advice on partitioning schemes that may improve performance.

The original workload manipulation has been deprecated and replaced by SQL tuning sets.

Partition Advisor

The SQL Access Advisor, originally introduced in Oracle 10g, has been updated to include advice on partitioning existing tables, materialized views and indexes. Partitioning exiting tables can be quite a lengthy process, so don\’t expect this advice to provide a quick fix.

Enhanced Statistics Collection for Partitioned Objects

Oracle 11g includes improvements to statistics collection for partitioned objects so untouched partitions are not rescanned. This significantly increases the speed of statistics collection on large tables where some of the partitions contain static data. Where partition exchange load (PEL) is used to add data to the a table, only the newly added partition must be scanned to update the global statistics.

12.SQL Query Repair Advisor

SQL Repair Advisor after a SQL statement fails with a critical error. The advisor analyzes the statement and in many cases recommends a patch to repair the statement. If you implement the recommendation, the applied SQL patch circumvents the failure by causing the query optimizer to choose an alternate execution plan for future executions.

13. SQL Performance Analyzer

SQL Performance Analyzer (SPA), a key feature of the Real Application Testing option introduced in Oracle Database 11g, can predict and prevent SQL execution performance problems caused by system changes.

SQL Performance Analyzer provides a granular view of the impact of changes on SQL execution plans and execution statistics by running the SQL statements in isolation before and after a change. SQL Performance Analyzer compares the SQL execution result, before and after the change, and generates a report outlining the net benefit on the workload due to the changes as well as the set of regressed SQL statements. For regressed SQL statements, appropriate executions plan details along with recommendations to remedy them are provided. SQL Performance Analyzer is well integrated with existing SQL Tuning Set (STS), SQL Tuning Advisor and SQL Plan Management functionalities. SQL Performance Analyzer completely automates and simplifies the manual and time-consuming process of assessing the impact of change on extremely large SQL workloads (thousands of SQL statements).

14.DBMS_STATS Enhancements

11g there have been some enhancements made to the DBMS_STATS package. Overall the GATHER_* processes run faster but what stands out to me is the speed and accuracy that DBMS_STATS.AUTO_SAMPLE_SIZE now gives. As a performance person, I often times make reference to letting the numbers tell the story, so lets dive into a comparison between 10.2.0.3 and 11.1.0.5.

15.The PL/SQL Result Cache

PL/SQL function result cache provides a simple way to boost the performance of PL/SQL functions by saving the results of function calls for specific combinations of input parameters in the SGA. These results can be reused by any session calling the same function with the same parameters. This can result in a significant performance boost when functions are called for each row in an SQL query, or within a loop in PL/SQL. This article describes the usage and administration of the function result cache.

Oracle Connection Behind Firewall

syedazad — Wed, 08 Jul 2009 11:39:51 +0000

PURPOSE
This article is intended to present the solutions to the problems with connecting the Oracle client to the Oracle database behind a firewall. The major reference here is the well-known Note 125021.1 [1]from Oracle Metalink, the secure customer extranet only accessible for Oracle customers and employees.
[edit]
Oracle Behind a Firewall
During a SQLPlus connection to the Oracle database, a remote Oracle client will check the database name supplied in the sqlplus line (sqlplus user/password@database)and search the tnsnames.ora file or the names server for a match. Once it obtains the address for the database server, the client will start an attempted connection to the server. The listener on the server is contacted, and then the information about the free port on the server is sent back to the client via the listener for the actual connection. Upon receiving the information, the client will try to connect the database server on that port.
Port redirection may occur during that process depending on the operating system, the configuration of the init.ora file and/or the Oracle product under discussion. Port redirection requires the Oracle client to connect to the database using a different port (usually a randomly selected TCP port) than the default or originally configured one. If there is no firewall between the server and the client, port redirection will not affect the actual connection. However, if port redirection does occur with the server behind a firewall, the client will be likely to suffer from a connectivity failure. The reason is simple: the newly assigned port based on port redirection is often blocked by the firewall. Such failures are not uncommon on Windows platforms.
[edit]
Case 1
[edit]
Problem Briefing
Reported Database Versions: Oracle 8.x – 9.2.0.7;
Server OS: Windows 2003 Sp2, Windows XP Sp2;
Client OS: Windows 2000 Sp4, Windows XP Sp2, Windows 2003 Sp2;
Description: When the Windows firewall is enabled on the Oracle database server, the Oracle client connecting the server often receives such error messages as ora-12203 and ora-12535:
ORA-12203: TNS:unable to connect to destination.
There may be an error in the fields entered or the server may not be ready for a connection. You can check the server and retry, or continue.
ORA-12535: TNS:operation timed out
There may be an error in the fields entered or the server may not be ready for a connection. You can check the server and retry, or continue.
[edit]
Solution
Step 1: Check to see whether Oracle Port 1521 has been added to the Windows Firewall exception list on the Oracle database server machine. If not, add Oracle Port 1521 to the Windows Firewall exception list on the server machine (which you can do through the Windows Firewall dialog in Control Panel > Windows Firewall, or adding it in the registry).
Step 2: Enable USE_SHARED_SOCKET on the Oracle database server. That will force the server machine to share its port 1521 and thus all clients will stay on that port when connecting to the database. Noticeably, port redirection will not occur with USE_SHARED_SOCKET enabled. To do this, you must add a string value USE_SHARED_SOCKET=TRUE in the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE section of the server’s registry. (Refer to Endnote 1)
Here is the text to create a reg key for both steps to add to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List]
“1521:TCP”=”1521:TCP:*:Enabled:Oracle Port 1521″
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE]
“USE_SHARED_SOCKET”=”TRUE”
Save the text into a file with the extension “.reg”. Then double-click the file on the server machine to add the information to its registry.
[edit]
Notice
The workaround here, suggested in Oracle Metalink Note 125021.1, is a WINSOCK V2 API feature called Shared Sockets. This feature allows a socket to be shared among multiple processes.
To use this functionality in a single Oracle Home enviroment, set USE_SHARED_SOCKET=TRUE in the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE section of the registry. Noticeably, as WINSOCK V2 allows a socket to be shared between multiple processes, the listener cannot be restarted without shutting down the database first.
A downfall of this solution is all connetions will stay on the listener port. If the listener is stopped or restarted all the connections will be severed from the database. Furthermore, USE_SHARED_SOCKET could be a performance bottleneck with multiple connections to the database. Please use it deliverately if many simultaneous connections to the database are involved.
[edit]
Case 2
[edit]
Problem Briefing
Reported Database Versions: Oracle 8.x – 9.2.0.7;
Server OS: Unix, including AIX, HP-UX, Linux and Solaris
Description: Connectivity failures may occur on Oracle database servers behind a firewall if they run in multi-threaded server mode(MTS). The reason is that Oracle Multi-Threaded Server (MTS) on Unix platforms will cause port redirection, and that the reassigned port is likely to be blocked.(Refer to Endnote 1)
[edit]
Solution
The workaround is to specify the port in the mts parameters of the init.ora file. The dispatcher will then be allowed to use the specified port, instead of the randomly selected port. Make sure that the specified port is open on the firewall. The following example shows the ports set to 8000 and 8001. Set the relevant parameters according to your individual systems.
Example
mts_dispatchers=”(address=(protocol=tcp)(host=hostname)(port=8000))(dispatchers=1)”
mts_dispatchers=”(address=(protocol=tcp)(host=hostname)(port=8001))(dispatchers=1)”

[edit]
ENDNOTE
1. Here is the reference from Oracle Metalink Note 125021.1:
A remote Oracle client making a connection to an Oracle database can fail if there is a firewall installed between the client and the server if there is port redirection. The firewall will block the port when the Oracle client connects to the database and can fail with the client receiving Oracle error ora-12203 or ora-12535. The Client connection failure is due to port redirection from the Windows operating system. Port redirection requires the Client to connect to the database using a different port than originally configured in the configuration ora files. Oracle MTS on Unix platforms, (without specifying the address with the ports in the init ora file), Oracle SSL, and NT platforms will cause port redirection.
Note 125021.1 suggests the following workarounds:
1. Firewall Vendor: The first solution is to contact the firewall vendor and see if they have an upgrade to allow for oracle connectivity with OS port redirection. If the firewall software can be upgraded, it is the best solution to follow.
2. Connection Manager: Use Connection Manager so that the TNS CONNECT following the REDIRECT happens on the server side of the firewall.
3. Use_Shared_Socket: A third solution for NT servers is to add the use_shared_socket = true into the registry (see 124140.1). This will allow the OS to share port 1521 and clients will then stay on 1521 when connecting to the database and will not be port redirected. A downfall of this option is all connetions will stay on the listener port and if the listener is stopped or restarted all the connections will be severed from the database.
2. Oracle Metalink Note 125021.1 also mentions how to solve the connecting problem in the SSL scenario:
Using SSL will cause Port redirection. The workaround is to select and set the ports using MTS in the init.ora, or by setting the Ports with Connection Manager in the cman.ora file.

Drop and Re-Create Database Console in Oracle

syedazad — Wed, 24 Jun 2009 09:32:36 +0000

Drop Database Console :-

To drop (remove) the configuration files and repository for Database Console, run:
$ emca -deconfig dbcontrol db -repos drop

STARTED EMCA at Jul 24, 2006 9:53:55 PM
EM Configuration Assistant, Version 10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle. All rights reserved.

Enter the following information:
Database SID: TESTDB
Listener port number: 1521
Password for SYS user: change_on_install
Password for SYSMAN user: manager

Do you wish to continue? [yes(Y)/no(N)]: Y
Jul 24, 2006 9:54:15 PM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/emca/TESTDB/emca_2006-07-24_09-53-55-PM.log.
Jul 24, 2006 9:54:16 PM oracle.sysman.emcp.util.DBControlUtil stopOMS
INFO: Stopping Database Control (this may take a while) …
Jul 24, 2006 9:54:35 PM oracle.sysman.emcp.EMReposConfig dropRepository
INFO: Dropping the EM repository (this may take a while) …
Jul 24, 2006 9:56:48 PM oracle.sysman.emcp.EMReposConfig invoke
INFO: Repository successfully dropped
Enterprise Manager configuration completed successfully
FINISHED EMCA at Jul 24, 2006 9:56:48 PM

________________________________________
Recreate Database Console :-

To recreate the configuration files and repository for Database Console, run:
$ emca -config dbcontrol db -repos recreate

STARTED EMCA at Jul 24, 2006 10:08:20 PM
EM Configuration Assistant, Version 10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle. All rights reserved.

Enter the following information:
Database SID: TESTDB
Database Control is already configured for the database TESTDB
You have chosen to configure Database Control for managing the database TESTDB
This will remove the existing configuration and the default settings and perform a fresh configuration
Do you wish to continue? [yes(Y)/no(N)]: Y
Listener port number: 1521
Password for SYS user: change_on_install
Password for DBSNMP user: manager
Password for SYSMAN user: manager
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
—————————————————————–

You have specified the following settings

Database ORACLE_HOME ……………. /u01/app/oracle/product/10.2.0/db_1

Database hostname ……………. linux3
Listener port number ……………. 1521
Database SID ……………. TESTDB
Email address for notifications ……………
Outgoing Mail (SMTP) server for notifications ……………

—————————————————————–
Do you wish to continue? [yes(Y)/no(N)]: Y

Data Guard Configuration Steps

syedazad — Thu, 18 Jun 2009 12:29:15 +0000

Always keep the Backup copy of the control file before any operation.

Identify the Primary Database Datafiles Primary
Make a Copy of the Primary Database Primary
Create a Control File for the Standby Database Primary
Prepare the Initialization Parameter File to be Copied to the Standby
Database Primary
Copy Files from the Primary System to the Standby System Primary
Set Initialization Parameters on a Physical Standby Database Standby
Create a Windows Service Standby
Configure Listeners for the Primary and Standby Databases Primary and Standby

Enable Dead Connection Detection on the Standby System Standby
Create Oracle Net Service Names Primary and Standby

Create a Server Parameter File for the Standby Database Standby
Start the Physical Standby Database Standby
Initiate Log Apply Services Standby
Enable Archiving to the Physical Standby Database Primary

1. Primary database should be in archive log mode:-
Connect as sysdba
SQL>Select log_mode from v$database; Or
Sql>Archive log list;
Sql>Alter database archivelog;

If automatic archival is not enabled then enable it using:-
Sql>Alter system Archive log start;
2. Enable Force Logging to Primary database:-
Sql>Alter database force logging; (It force the writing of redo records. FORCE LOGGING is to ensure complete media recovery while it degrade the performance.)

Antonym:
(Alter database noarchivelog;
Alter database no force logging;)

3. Set the local archive destination:-
Sql>Alter system set log_archive_dest_1=’LOCATION=d:\oradata\oraHome92\oradata\BST1 Mandatory’ scope=BOTH;
4. Identifying the Pr. Database datafile:-
Sql>Select name from V$DATAFILE;
5. Make a copy of the Pr.database file:-
Sql>Alter system switch logfile;
Sql>shutdown immediate;

Now copy all the datafile and place into a temp folder to transfer to Standby Site.

Sql>Startup;

6. Now make a standby control file:-
Sql>Alter database create standby controlfile as ‘d:\oradata\oraHome92\oradata\BST1\Stby_Cf.ctl’;
7. Prepare the Initialization Parameter file to be copied to the Standby Site:-
Sql>Create PFILE=’d:\oradata\oraHome92\dbs\InitStby.ora’ from SPFILE;

8. Transfer the Backup datafile,Control file and InitStby initialization file to the Standby site at same position.
9. Modify the Initialization file on Primary and Standby site both as follows:-
On Pr.Dbase:—
Log_ archive_dest_1=’LOCATION=d:\oradata\oraHome92\oradata\BST1\Arch _ive REOPEN=5 MAX_FAILURE=3’
Log_archive_dest_2=’SERVICE=BST1SBY LGWR ASYNC AFFIRM’(or BST1 whatever oracleNetServiceName is.)
Log_archive_dest_state_1=enable
Log_archive_dest_state_2=enable

On Standby Site:—

Log_ archive_dest_1=’LOCATION=d:\oradata\oraHome92\oradata\BST1\Archive’
Log_archive_dest_2=’SERVICE=BST1SBY LGWR ASYNC AFFIRM’(or BST1 whatever oracleNetServiceName is.)
Log_archive_dest_state_1=enable
Log_archive_dest_state_2=enable
Log_archive_start=true
Standby_file_management=AUTO
Remote_archive_enable=true
Remote_archive_dest=’D:\….\….\…\Archive’
Fal_server=Primary1(net service name on the standby machine for Pr.Dbase)  optional
Fal_Client=BST1SBY(net service name on the Pr.Dbase for standby
dbase)  optional

10. Create Oracle Net configuration on both the machine to connect each other.
Eg.
Tnsnames.ora File on Primary site will look like
# standby db identification on Pr. Site
BST1SBY.RAMTECH.COM =  Net Service Name Standby host
(DESCRIPTION = of Stby db.
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = RAMTECH-144)(PORT = 1521))
)
(CONNECT_DATA =
(SID = KGIS)
)
)

Tnsnames.ora File on Standby site will look like
# Primary db identification on Standby Site
PRIMARY1.RAMTECH.COM =  Net Service Name pr.Host
(DESCRIPTION = of Pr.Db.
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = RAMTECH-201)(PORT = 1521))
)
(CONNECT_DATA =
(SID = KGIS)
)
)
BST1.RAMTECH.COM=->GLOBALNAME TO ACCESS FOR EX.CONNECT SYS/RAMTECH@BST1

(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ramtech-117)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID= BST1SBY) —->> ORADIM…SID NAME
)
)

Listener.ora File on Standby site will look like
Add the standby database details in listener file on Standby machine.
No changes reqd in listener file on Pr. Machine.

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ramtech-144)(PORT = 1521))
)
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oradata\oraHome92)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = BST1)
(ORACLE_HOME = D:\oradata\oraHome92)
(SID_NAME = BST1SBY)
)
)

11. Create a window service on Standby machine:-
C:\>oradim –NEW –SID BST1SBY –STARTMODE MANUAL
–PFILE D:\oradata\oraHome92\dbs\file_name.ora

12. Stop and Start the listener:-
C:\>lsnrctl stop/reload/start/status

13. Enable the dead connection detection on the Standby site in SQLNET.ORA file in admin folder
SQLNET.Expire_time=2
SQLNET.AUTHENTICATION_SERVICES= (NTS)

14. Create a Password file on Standby site:-
C:\>orapwd file= D:\oradata\oraHome92\database\PWDBST1Sby.ora password=ramtech entries=10

15. Create a Server parameter file on Standby database:
Note:- Before creating SPFILE make sure that all the necessary Initialization parameter text file entries done.

Sql>connect sys/ramtech@BST1 as sysdba
Connected to an idle instance.
Note:–If there is End –Of-File Communication error comes,then first restart the service and after that connect to an idle instance and then create spfile from pfile.

Sql>create SPFILE from PFILE=’ D:\oradata\oraHome92\dbs\file_name.ora’

16. start the standby database:-
Sql>startup nomount;
Sql>alter database mount standby database;
Sql>alter database recover managed standby database disconnect from session;
17. On Primary site:-
Enable archiving as follows:-
Sql>Alter system set log_archive_dest_2=’SERVICE=BST1SBY LGWR ASYNC AFFIRM’;

Sql>Alter system set log_archive_dest_state_2=Enable;
18. Start Remote archiving on Pr.database to push log file manually:-
Sql>Alter system archive log current;

19. Check the update on Standby site:-
Sql>alter database recover managed standby database CANCEL;
Sql>alter database open read only;
Sql>select * from scott.emp;(Check update if any)

20. To bring up the database in recovery mode shutdown it first and then startup nomount……….like before till alter database recover …..statement.

For Maximum Protection:-
Log_archive_dest_3=’SERVICE=BST1SBY LGWR SYNC AFFIRM’

Start database in mount mode (not open)
Sql>Alter database set standby database to maximize protection;

(By default protection mode is Maximize performance)

Note:-ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
You execute this statement on the primary database, which must be stopped and in the mount state.

Find Gap:
select thread#,low_sequence#,high_sequence# from V$archive_gap;

Status of individual archived log on Standby site :-

select thread#,Sequence#,Applied,Registrar from V$Archived_Log;

ARCHIVE_LAG_TARGET
Description
Limits the amount of data that can be lost and effectively increases the availability
of the standby database by forcing a log switch after the amount of time you specify
(in seconds) elapses. The standby database will not miss redo logs generated from a
time range longer than a value of the ARCHIVE_LAG_TARGET parameter.
Role
Applies to the primary database role
Examples
The following example sets the log switch interval to 30 minutes (a typical value):
ARCHIVE_LAG_TARGET = 1800

Role Management 7-11
7.2.1 Switchover Operations Involving a Physical Standby Database
This section describes how to perform a switchover operation that changes roles
between a primary database and a physical standby database. Always initiate the
switchover operation on the primary database and complete it on the physical
standby database. The following steps describe how to perform the switchover
operation.
On the current primary database
Step 1 Verify that it is possible to perform a switchover operation.
On the current primary database, query the SWITCHOVER_STATUS column of the
V$DATABASE fixed view on the primary database to verify that it is possible to
perform a switchover operation. For example:
Role Transitions Involving Physical Standby Databases
7-12 Oracle9i Data Guard Concepts and Administration
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
—————–
TO STANDBY
1 row selected
The TO STANDBY value in the SWITCHOVER_STATUS column indicates that it is
possible to switch the primary database to the standby role. If the TO STANDBY
value is not displayed, then verify that the Data Guard configuration is functioning
correctly (for example, verify that all LOG_ARCHIVE_DEST_n parameter values are
specified correctly).
Step 2 Initiate the switchover operation on the primary database.
To transition the current primary database to a physical standby database role, use
the following SQL statement on the primary database:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
After this statement completes, the primary database is converted into a standby
database. The current control file is backed up to the current SQL session trace file
before the switchover operation. This makes it possible to reconstruct a current
control file, if necessary.
Step 3 Shut down and restart the former primary instance.
Shut down the former primary instance and restart it without mounting the
database:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP NOMOUNT;
Mount the database as a physical standby database:
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
At this point in the switchover process, both databases are configured as standby
databases (see Figure 7–3).
See Also: Chapter 14 for information about other valid values for
the SWITCHOVER_STATUS column of the V$DATABASE view
Role Transitions Involving Physical Standby Databases
Role Management 7-13
On the target physical standby database
Step 4 Verify the switchover status in the V$DATABASE view.
After you transition the primary database to the physical standby role and the
switchover notification is received by the standby databases in the configuration,
you should verify if the switchover notification was processed by the target standby
database by querying the SWITCHOVER_STATUS column of the V$DATABASE fixed
view on the target standby database.
For example:
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
—————–
SWITCHOVER PENDING
1 row selected
The SWITCHOVER PENDING value of the SWITCHOVER_STATUS column indicates
the standby database is about to switch from the standby role to the primary role. If
the SWITCHOVER PENDING value is not displayed, then verify that the Data Guard
configuration is functioning correctly (for example, verify that all LOG_ARCHIVE_
DEST_n parameter values are specified correctly).
Step 5 Switch the physical standby database role to the primary role.
You can switch a physical standby database from the standby role to the primary
role when the standby database instance is either mounted in managed recovery
mode or open for read-only access. It must be mounted in one of these modes so
that the primary database switchover operation request can be coordinated.
The SQL ALTER DATABASE statement used to perform the switchover
automatically creates online redo logs if they do not already exist. This might
significantly increase the time required to complete the COMMIT operation.
Therefore, Oracle Corporation recommends that you always manually add online
redo logs to the target standby database when you create it. Use one of the
following methods to manually add the online redo logs if they do not already exist:
_ Copy the existing online redo logs from the initial primary database site to the
target standby database site and define the LOG_FILE_NAME_CONVERT
initialization parameter to correctly associate the standby site path names to the
new online redo logs (see Section 3.2.6).
See Also: Chapter 14 for information about other valid values for
the SWITCHOVER_STATUS column of the V$DATABASE view
Role Transitions Involving Physical Standby Databases
_ Drop any existing online redo logs at the target standby site and create new
ones using the ALTER DATABASE ADD STANDBY LOGFILE statement.
After you manually add the online redo logs, use the following SQL statement on
the physical standby database that you want to transition to the primary role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Step 6 Shut down and restart the new primary database.
Shut down the target standby instance and restart it using the appropriate
initialization parameters for the primary role:
SQL> SHUTDOWN;
SQL> STARTUP;
The target physical standby database is now transitioned to the primary database
role.
On the new physical standby database
Step 7 Start managed recovery operations and log apply services.
Issue the following statement to begin managed recovery operations on the new
physical standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
On the new primary database
Step 8 Begin sending redo data to the standby databases.
Issue the following statement on the new primary database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Media recovery:

SQL>RECOVER MANAGED STANDBY DATABASE disconnect from session;
SQL> recover managed standby database cancel;
Both the above 2 cmds for complete media recovery.
Switchover

wanted to do a failover test. so i aborted my primary and activated my standby as primary using the following commands

recover managed standby database finish;
alter database commit to switchover to primary with session shutdown;
shutdown immediate;
startup

Important:

1. Initiate the failover operation on the target physical standby database
Since our Data Guard configuration was set up in maximum performance mode, it was not configured with any standby redo logs. Therefore, run the following SQL statement from the target physical standby database to initiate the failover operation. Please keep in mind that this statement will cause (minimal) data loss as the latest information from the down primary database is not available anymore.
SQL> alter database recover managed standby database finish skip standby logfile;

Database altered.
The above SQL statement performs incomplete
recovery until the last SCN included in the latest archived redo log available at the physical standby database. The next section describes the final step which is to make the target standby database the primary.
If your Data Guard configuration did contain standby redo logs (as required with protection modes like maximum availability and maximum protection AND you have not registered any partial archived redo log files, then you need to stop normal managed recovery and then initiate the failover operation using the following SQL statements:
SQL> alter database recover managed standby database cancel;

Database altered.

SQL> alter database recover managed standby database finish;

Database altered.

2. Convert the physical standby database to the primary role
After the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE … FINISH; SQL statement successfully completes, you will then need to transition the target physical standby database to the primary database role by issuing the following SQL statement:
SQL> alter database commit to switchover to primary;

The above SQL statement will only succeed if the correct “ALTER DATABASE RECOVER MANAGED STANDBY DATABASE … FINISH;” statement was issued (in the previous section). If you forgot the “…SKIP STANDBY LOGFILE” clause although you have no standby redo log files, the “COMMIT TO SWITCHOVER” will fail with the error that more media recovery is required here.
If the “COMMIT TO SWITCHOVER” fails for any reason, you have to use the “ACTIVATE” SQL statement which forces the failover operation (and may cause data loss!):
SQL> alter database activate standby database;

Database altered.
After the “COMMIT TO SWITCHOVER” successfully completes, you can no longer use this database as a standby database. Also, subsequent redo logs from the original primary database cannot be applied.
Execute this statement if media recovery error comes:–
SQL> alter database activate standby database; and now shutdown as below…
3. Shutdown and restart the new primary database
To complete the failover operation, you need to shutdown the new primary database and restart it in read/write mode using the appropriate initialization parameter file (or SPFILE) for the primary role:
SQL> shutdown immediate
ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area 252777556 bytes
Fixed Size 451668 bytes
Variable Size 218103808 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.