Microsoft recommend that you install security software to help protect your computer from viruses and other security threats, and that you keep your security software up to date.
The companies listed below provide consumer security software that is compatible with Windows 7. Just click the company name to see the Windows 7-compatible product they offer. For business security software that is compatible with Windows 7, please visit the Windows 7 Compatibility Center or contact your security vendor of choice.
Microsoft is actively working with the partners listed on this page and additional security independent software vendors (ISVs) to provide security software solutions tested on Windows 7.
Source : http://www.microsoft.com/windows/antivirus-partners/windows-7.aspx
Thursday, December 31, 2009
Saturday, December 5, 2009
Oracle Data Guard (Introduction)
Oracle Data Guard is the management, monitoring, and automation software infrastructure that creates, maintains, and monitors one or more standby databases to protect enterprise data from failures, disasters, errors, and corruptions.
Data Guard maintains these standby databases as transactionally consistent copies of the production database. These standby databases can be located at remote disaster recovery sites thousands of miles away from the production data center, or they may be located in the same city, same campus, or even in the same building. If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage, and preventing any data loss.
Available as a feature of the Enterprise Edition of the Oracle Database, Data Guard can be used in combination with other Oracle High Availability (HA) solutions such as Real Application Clusters (RAC), Oracle Flashback and Oracle Recovery Manager (RMAN), to provide a very high level of data protection and data availability that is unprecedented in the industry..
Data Guard Configurations
A Data Guard configuration consists of one production (formally known as primary) database and up to nine/9 standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided that they can communicate with each other. However, for disaster recovery, it is recommended that the standby databases be hosted at sites that are geographically separated from the primary site.
· Primary Database
A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications. The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.
· Standby Database
A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database. Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.
Standby Database Types
Following are the standby database types:
An Active Data Guard standby database is an exact copy of the primary that is open read-only while it continuously applies changes transmitted by the primary database. An active standby can offload ad-hoc queries, reporting, and fast incremental backups from the primary database, improving performance and scalability while preventing data loss or downtime due to data corruptions, database and site failures, human error, or natural disaster.
· Snapshot Standby
A snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. The redo data received from the primary database is applied once a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
· Logical standby database
A logical standby database contains the same logical information as the production database, although the physical organization and structure of the data can be different. The SQL apply technology keeps the logical standby database synchronized with the primary database by transforming the data in the redo logs received from the primary database into SQL statements and then executing the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This makes it possible for the logical standby database to be accessed for queries and reporting purposes at the same time the SQL is being applied to it. Thus, a logical standby database can be used concurrently for data protection and reporting and database upgrades.
Data Guard provides two methods to apply this redo data to the standby database and keep it transactionally consistent with the primary, and these methods correspond to the two types of standby databases supported by Data Guard. Redo Apply, used for Physical Standby databases SQL Apply, used for Physical Standby databases
Data Guard Protection Modes
Data Guard provides three modes of data protection to balance cost, availability, performance, and data protection. These modes define the rules that govern the behavior of the Data Guard configuration, and can be set easily using any of the available management interfaces, e.g. using the following simple SQL statement on the primary database:
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION AVAILABILITY PERFORMANCE};
To determine the appropriate data protection mode, enterprises need to weigh their business requirements for data protection against user demands for system response time. The following table outlines the suitability of each mode from a risk of data loss perspective.
· Maximum Protection—This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode ensures no-data-loss.
· Maximum Availability—This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
· Maximum Performance—This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database and there is little effect on primary database performance
Data Guard Services
The following sections explain how Data Guard manages the transmission of redo data, the application of redo data, and changes to the database roles:
Log Transport Services—Control the automated transfer of redo data from the production database to one or more archival destinations.
Log Apply Services—Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.
Data Guard provides two methods to apply this redo data to the standby database and keep it transactionally consistent with the primary, and these methods correspond to the two types of standby databases supported by Data Guard.
Redo Apply, used for Physical Standby databases
SQL Apply, used for Physical Standby databases
Role Management Services
Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.
A database can operate in one of the two mutually exclusive roles: primary or standby database.
· Failover During a failover, one of the standby databases takes the new primary database role, when an unplanned failure occurs on the primary database. This enables recovery time objectives to be achieved by quickly promoting the standby to the primary role instead incurring downtime while the events that impact the primary are diagnosed and resolved.
· Switchover A switchover is used to reduce primary database downtime during planned outages, such as operating system or hardware upgrades, or rolling upgrades of the Oracle database software and patch sets. A switchover operation requires all user sessions to be disconnected from the primary database. Following that, the primary database is transitioned to the standby role, after which the standby database is transitioned to the primary role.For example – the following single Data Guard Broker CLI (DGMGRL) command initiates and completes the switchover to the standby database “Chicago”:
DGMGRL> SWITCHOVER TO STANDBY;
Once initiated, Data Guard automates the actual role transition processes. No data is lost in the process.
· Fast-Start Failure
Fast-Start Failover Fast-Start Failover allows Data Guard to automatically fail over to a previously chosen, standby database without requiring any manual steps to invoke the failover. Further, upon return of the failed primary, it is automatically reinstated into the configuration as a standby of the new primary database. Fast-Start Failover can be used only in a Data Guard Broker configuration and can be configured only through DGMGRL or Enterprise Manager.
DGMGRL> FAILOVER TO STANDBY;
A manual failover operation ensures zero data loss if Data Guard was being run in the Maximum Protection or Maximum Availability and the target standby database was synchronized at the time of the failover.
Primary and standby database can continue to alternate roles. The primary database can switch the role to a standby database; and one of the standby databases can switch roles to become the primary.
The main difference between physical and logical standby databases is the manner in which log apply services apply the archived redo data:
For physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure.
For logical standby databases, Data Guard uses SQL Apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database.
Data Guard Interfaces
Oracle provides three ways to manage a Data Guard environment:
1. SQL*Plus and SQL Statements
Using SQL*Plus and SQL commands to manage Data Guard environment. The following SQL statement initiates a switchover operation:
SQL> alter database commit to switchover to physical standby;
2. Data Guard Broker GUI Interface (Data Guard Manager)
Data Guard Manger is a GUI version of Data Guard broker interface that allows you to automate many of the tasks involved in configuring and monitoring a Data Guard environment.
3. Data Guard Broker Command-Line Interface (CLI)
It is an alternative interface to using the Data Guard Manger. It is useful if you want to use the broker from batch programs or scripts. You can perform most of the activities required to manage and monitor the Data Guard environment using the CLI.
The Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations.
You can perform all management operations locally or remotely through the broker’s easy-to-use interfaces: the Data Guard web pages of Oracle Enterprise Manager, which is the broker’s graphical user interface (GUI), and the Data Guard command-line interface (CLI) called DGMGRL.
.
Data Guard maintains these standby databases as transactionally consistent copies of the production database. These standby databases can be located at remote disaster recovery sites thousands of miles away from the production data center, or they may be located in the same city, same campus, or even in the same building. If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage, and preventing any data loss.
Available as a feature of the Enterprise Edition of the Oracle Database, Data Guard can be used in combination with other Oracle High Availability (HA) solutions such as Real Application Clusters (RAC), Oracle Flashback and Oracle Recovery Manager (RMAN), to provide a very high level of data protection and data availability that is unprecedented in the industry..
Data Guard Configurations
A Data Guard configuration consists of one production (formally known as primary) database and up to nine/9 standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided that they can communicate with each other. However, for disaster recovery, it is recommended that the standby databases be hosted at sites that are geographically separated from the primary site.
· Primary Database
A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications. The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.
· Standby Database
A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database. Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.
Standby Database Types
Following are the standby database types:
· Physical Standby Database- A physical standby database provides a physically identical copy of the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The database schemas, including indexes, are the same. The Redo Apply technology applies redo data on the physical standby database using standard Oracle media recovery techniques.
· Active Data GuardAn Active Data Guard standby database is an exact copy of the primary that is open read-only while it continuously applies changes transmitted by the primary database. An active standby can offload ad-hoc queries, reporting, and fast incremental backups from the primary database, improving performance and scalability while preventing data loss or downtime due to data corruptions, database and site failures, human error, or natural disaster.
· Snapshot Standby
A snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. The redo data received from the primary database is applied once a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
· Logical standby database
A logical standby database contains the same logical information as the production database, although the physical organization and structure of the data can be different. The SQL apply technology keeps the logical standby database synchronized with the primary database by transforming the data in the redo logs received from the primary database into SQL statements and then executing the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This makes it possible for the logical standby database to be accessed for queries and reporting purposes at the same time the SQL is being applied to it. Thus, a logical standby database can be used concurrently for data protection and reporting and database upgrades.
Data Guard provides two methods to apply this redo data to the standby database and keep it transactionally consistent with the primary, and these methods correspond to the two types of standby databases supported by Data Guard. Redo Apply, used for Physical Standby databases SQL Apply, used for Physical Standby databases
Data Guard Protection Modes
Data Guard provides three modes of data protection to balance cost, availability, performance, and data protection. These modes define the rules that govern the behavior of the Data Guard configuration, and can be set easily using any of the available management interfaces, e.g. using the following simple SQL statement on the primary database:
SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION AVAILABILITY PERFORMANCE};
To determine the appropriate data protection mode, enterprises need to weigh their business requirements for data protection against user demands for system response time. The following table outlines the suitability of each mode from a risk of data loss perspective.
· Maximum Protection—This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode ensures no-data-loss.
· Maximum Availability—This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
· Maximum Performance—This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing continues on the primary database and there is little effect on primary database performance
Data Guard Services
The following sections explain how Data Guard manages the transmission of redo data, the application of redo data, and changes to the database roles:
Log Transport Services—Control the automated transfer of redo data from the production database to one or more archival destinations.
Log Apply Services—Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.
Data Guard provides two methods to apply this redo data to the standby database and keep it transactionally consistent with the primary, and these methods correspond to the two types of standby databases supported by Data Guard.
Redo Apply, used for Physical Standby databases
SQL Apply, used for Physical Standby databases
Role Management Services
Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.
A database can operate in one of the two mutually exclusive roles: primary or standby database.
· Failover During a failover, one of the standby databases takes the new primary database role, when an unplanned failure occurs on the primary database. This enables recovery time objectives to be achieved by quickly promoting the standby to the primary role instead incurring downtime while the events that impact the primary are diagnosed and resolved.
· Switchover A switchover is used to reduce primary database downtime during planned outages, such as operating system or hardware upgrades, or rolling upgrades of the Oracle database software and patch sets. A switchover operation requires all user sessions to be disconnected from the primary database. Following that, the primary database is transitioned to the standby role, after which the standby database is transitioned to the primary role.For example – the following single Data Guard Broker CLI (DGMGRL) command initiates and completes the switchover to the standby database “Chicago”:
DGMGRL> SWITCHOVER TO STANDBY;
Once initiated, Data Guard automates the actual role transition processes. No data is lost in the process.
· Fast-Start Failure
Fast-Start Failover Fast-Start Failover allows Data Guard to automatically fail over to a previously chosen, standby database without requiring any manual steps to invoke the failover. Further, upon return of the failed primary, it is automatically reinstated into the configuration as a standby of the new primary database. Fast-Start Failover can be used only in a Data Guard Broker configuration and can be configured only through DGMGRL or Enterprise Manager.
DGMGRL> FAILOVER TO STANDBY;
A manual failover operation ensures zero data loss if Data Guard was being run in the Maximum Protection or Maximum Availability and the target standby database was synchronized at the time of the failover.
Primary and standby database can continue to alternate roles. The primary database can switch the role to a standby database; and one of the standby databases can switch roles to become the primary.
The main difference between physical and logical standby databases is the manner in which log apply services apply the archived redo data:
For physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure.
For logical standby databases, Data Guard uses SQL Apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database.
Data Guard Interfaces
Oracle provides three ways to manage a Data Guard environment:
1. SQL*Plus and SQL Statements
Using SQL*Plus and SQL commands to manage Data Guard environment. The following SQL statement initiates a switchover operation:
SQL> alter database commit to switchover to physical standby;
2. Data Guard Broker GUI Interface (Data Guard Manager)
Data Guard Manger is a GUI version of Data Guard broker interface that allows you to automate many of the tasks involved in configuring and monitoring a Data Guard environment.
3. Data Guard Broker Command-Line Interface (CLI)
It is an alternative interface to using the Data Guard Manger. It is useful if you want to use the broker from batch programs or scripts. You can perform most of the activities required to manage and monitor the Data Guard environment using the CLI.
The Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations.
You can perform all management operations locally or remotely through the broker’s easy-to-use interfaces: the Data Guard web pages of Oracle Enterprise Manager, which is the broker’s graphical user interface (GUI), and the Data Guard command-line interface (CLI) called DGMGRL.
.
Friday, December 4, 2009
Physical Standby Database - Step by Step Configuration
Server : HP 386 2 x Xeon 3.4 (6GB RAM, HDD 73x3)
Operating System : Microsoft Windows Server 2003 x86
Database : Oracle 10gR2, 11gR1
IP Address :192.168.1.29, 192.168.1.30
Host Name :dbserver, physicaldb
Database Unique Name : orcl, physicaldb
Service Name :primarydb, physicaldb
Note: following steps required for physical standby database
1. Pre-Installation Configuration
2. Installing Oracle Software and Database
3. Prepare Production Database as Primary Database
3.1. Enable and Verify Archive Log mode
3.2. Enable force longing
3.3. Create STANDBY redo log
3.4. Create STANDBY control file for standby database
3.5. Create PFILE from SPFILE and set primary and standby database initialization parameters file
3.6. Backup Primary Database, copy on standby nodes
3.7. Startup primary database in mount mode using PFILE and create binary/SPFILE file from PFILE
4. Configure listener and tnsnames files on primary and standby database nodes
5. Prepare standby database node
5.1. Copy primary database backup at standby nodes at same directories
5.2. Copy and change standby control file which created in step 3.4 (standby.ctl to control01.ctl etc)
5.3. Copy and change standby initialization parameter file witch create in step 3.5
5.4. Create a window based service for standby instance, using the ORADIM
5.5. Set environment variables (ORACLE_HOME, ORACLE_SID) to point the standby database
5.6. Startup standby database in nomount mode and create SPFILE from PFILE
5.7. Startup Standby database in mount mode and perform recovery
6. Verify the physical standby database is performing properly
Follow Following Steps for deploying Oracle Physical Standby Database Microsoft Windows
1. Pre-Installation Configuration
Check operating system install and working properly, confirm ip and hostnames on all nodes.
2. Install Oracle Software and Database
Install Oracle Database software on primary node
Install only Oracle software on Standby Nods.
3. Prepare production database for Primary database
3.1 If production/primary database not in archive mode, first enable archive log mode.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ARCHIVE LOG LIST;
SQL> ALTER DATABASE FLASHBACK ON;
3.2 Enable force longing
SQL> ALTER DATABASE FORCE LOGGING;
Verify archive log mode and force logging
SQL> SELECT LOG_MODE, FLASHBACK_ON, FORCE_LOGGING FROM V$DATABASE;
3.3 Create Standby Redo Log
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('D:\oracle\product\10.2.0\oradata\ORCL\REDO11.LOG') SIZE 51200K;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('D:\oracle\product\10.2.0\oradata\ORCL\REDO12.LOG') SIZE 51200K;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('D:\oracle\product\10.2.0\oradata\ORCL\REDO13.LOG') SIZE 51200K;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('D:\oracle\product\10.2.0\oradata\ORCL\REDO14.LOG') SIZE 51200K;
Check Primary Database redo log
SQL> SELECT * FROM V$LOGFILE;
Check Standby Database redo log
SQL> SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;
3.4 Create STANDBY control file for standby database
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'D:\oracle\physical.ctl';
3.5 Create PFILE from SPFILE and Set Primary/Standby Database initialization Parameters
SQL> CREATE PFILE='D:\Oracle\INITorcl.ora' FROM SPFILE;
Edit the PFILE parameter for primary configuration, here shown colored:
db_domain=''
db_name='orcl'
instance_name='orcl'
db_unique_name='orcl'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,physicaldb)'
LOG_ARCHIVE_DEST_1='LOCATION=D:\oracle\product\10.2.0\oradata\ORCL\ARCHIVE VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'
LOG_ARCHIVE_DEST_2='SERVICE=physicaldb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=physicaldb'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=10
fal_server=physicaldb
fal_client=orcl
standby_file_management=auto
Copy primary PFILE and change database initialization parameter file for standby database
db_domain=''
db_name='orcl'
instance_name='orcl'
db_unique_name='logicaldb'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,logicaldb)'
LOG_ARCHIVE_DEST_1='LOCATION=D:\oracle\product\10.2.0\oradata\ORCL\ARCHIVE VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=physicaldb'
LOG_ARCHIVE_DEST_2='SERVICE=orcl LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
#LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=10
fal_server=orcl
fal_client=phsicaldb
standby_file_management=auto
3.6 Use RMAN for backup or copy database folders (ORADATA, ADMIN, Recovery_Flash_Area), standby
Parameters and control files at standby nodes.
3.7 Startup in mount mode using PFILE and Create binary/SPFILE file from PFILE
SQL> STARTUP NOMOUNT PFILE='D:\ORACLE\initorcl.ora';
SQL> CREATE SPFILE FROM PFILE='D:\ORACLE\initorcl.ora';
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4. Configure Listener and services on all nodes
On Production/Primary node Listener and service automatically created for primary database during installing, just add/create standby service. Create Listener and services (orcl, primarydb,physicaldb) at standby node that will be used by log transport services. For configuration use Oracle Net Manger or directly copy/paste and edit primary (listener.ora and tnsnames.ora) files. After configuration check services.
Note : Its recemended use Oracle supplied utility NETCA, NETMGR
After configuring listnners and services try to connect standby database from primary node, and from standby node to primary database. Following connections should work now, first check listener from primary and standby nodes.
C:\> TNSPING orcl
C:\> TNSPING physicaldb
From Primary host
SQL:>sys/oracle@orcl as sysdba –> This will connect to primary database
SQL:>sys/oracle@physicaldb as sysdba –> It will connect to standby database from primary host
From Standby host
sqlplus sys/oracle@orcl as sysdba –> This will connect to primary database from standby host
sqlplus sys/oracle@physicaldb as sysdba –> This will connect to standby database
5. Prepare standby nods Step by Step
5.1 Copy primary database backup at standby nodes at same directories use OS commands.
5.2 Copy and change standby control file (change standby.ctl rename to control01.ctl,2,3 etc)
5.3 Copy changed standby initialization parameter file on standby node witch create in step 3.5
5.4 Create a window based service for standby instance, using the ORADIM
C:\>ORADIM –NEW –SID orcl –INTPWD oracle –STARTMODE manual
5.5 Create password file.
C:\>ORAPWD FILE=PWDstandby.ora PASSWPRD=SECRET ENTRIES=20 FORCE=Y
5.6 Set environment variables (ORACLE_HOME, ORACLE_SID) to point the standby database in window’s registry.
5.7 Startup standby database in nomount mode and create SPFILE from PFILE
SQL> STARTUP NOMOUNT PFILE='D:\Oracle\initphysicaldb.ora' ;
SQL> CREATE SPFILE FORM PFILE='D:\Oracle\initphysicaldb.ora';
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
5.8 Startup standby database in mount mode and perform recovery.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
View primary and standby database alert logs.
6. Verify the Physical Standby database
Check archived redo log on Standby
First check database parameter’s values
SQL> SHOW PARAMETERS DB_UNIQUE_NAME;
SQL> ARCHIVE LOG LIST;
SQL> SELECT NAME,DB_UNIQUE_NAME,LOG_MODE,FORCE_LOGGING FROM V$DATABASE;
Now, Check archived redo log
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
Switch log files on Primary
SQL> ALTER SYSTEM SWITCH LOGFILE;
Check Archived Statistics
SQL> ARCHIVE LOG LIST;
Check archived redo log on Standby
SQL> SELECT SEQUENCE#,FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
Thursday, December 3, 2009
Active Data Guard - Step by Step Configuration
With Oracle Database 11g, we can open the physical standby database in read-only mode and restart the recovery process. This means we can continue to be in sync with primary but can use the standby for reporting. Let's see how it is done. Make sure Logical Physical Standby database is working properly.
First, cancel the managed standby recovery and open database as read only:
SQL> alter database recover managed standby database cancel;
SQL> alter database open read only;
While the standby database is open in read-only mode, we can resume the managed recovery process.
SQL> alter database recover managed standby database disconnect;
Now the standby database has been placed in managed recovery mode applying the log files while it is open. Confirm, changes applying on standby database
On the primary create any table, do a log switch and check the maximum log sequence number:
SQL> create table test (cd number);
SQL> alter system switch logfile;
SQL> select max(Sequence#) from v$log;
Connect sys/password@standbydb as sysdba
SQL> select max(Sequence#) from v$log;
SQL> describe test;
The table Description appears in standby, and is ready to be queried.
First, cancel the managed standby recovery and open database as read only:
SQL> alter database recover managed standby database cancel;
SQL> alter database open read only;
While the standby database is open in read-only mode, we can resume the managed recovery process.
SQL> alter database recover managed standby database disconnect;
Now the standby database has been placed in managed recovery mode applying the log files while it is open. Confirm, changes applying on standby database
On the primary create any table, do a log switch and check the maximum log sequence number:
SQL> create table test (cd number);
SQL> alter system switch logfile;
SQL> select max(Sequence#) from v$log;
Connect sys/password@standbydb as sysdba
SQL> select max(Sequence#) from v$log;
SQL> describe test;
The table Description appears in standby, and is ready to be queried.
Wednesday, December 2, 2009
Logical Standby Database - Step by Step Configuration
Conversion from Physical to Logical Standby
Step (1) Create PHYSICAL STANDBY DATABASE and make sure working properly.
Step (2) Prepare the Primary Database to Support a Logical Standby Database
1. Enable supplemental logging
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
2. Update undo_retention system parameter
SQL> ALTER SYSTEM SET UNDO_RETENTION=3600;
3. Create new directory/folder for new logical standby archive log and enable.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='LOCATION=/oradisk/archive/orcl/standbylog VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=orcl';
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE;
4. On the primary database, issue the following to build the LogMiner tables for dictionary:
SQL> execute dbms_logstdby.build;
Step (3) Stop Recovery Process on Standby Database and convert it to Logical Database
On the standby database, stop the managed recovery process:
SQL> alter database recover managed standby database cancel;
Now, issue the command in standby side to convert it to logical:
SQL> alter database recover to logical standby logicaldb;
Note: If you didn't execute Step 2.1,2.4, the above command will wait since the dictionary information is not found. Don't worry; just execute the Step 2.4 at this point. Issue a few log switches on primary to make sure the archived logs are created and sent over to the standby:
SQL> alter system switch logfile;
On the standby side, you can see that the alter database command has completed, after some time. Now the standby is a logical one. You will see the following line in alert log:
RFS[12]: Identified database type as 'logical standby'
Recycle the database, and start SQL Apply process on new logical standby database :
SQL> shutdown
SQL> startup mount
SQL> alter database open resetlogs;
SQL> alter database start logical standby apply immediate;
The logical standby database is now fully operational! Once you convert the physical standby to a logical one, you can't convert it back to a physical one unless you use the special clause ("keep identity)
SQL> alter database recover to logical standby keep identity;
Database altered.
See more detailed step-by-step instructions in the documentation.
Tuesday, December 1, 2009
Snapshot Standby - Step by Step Configuration
Snapshot standby database is a fully updateable standby database created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. The redo data received from the primary database is applied once a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
1. Configured flash recovery area, check database flashback enable, must enable it if not.
SQL> alter system set db_recovery_file_dest_size = 2G;SQL> alter system set db_recovery_file_dest= '/db_recov';
SQL> SELECT FLASHBACK_ON FROM V$DATABASE;
2. Cancel managed recovery mode on physical standby database
SQL> alter database recover managed standby database cancel;
3. Convert physical standby database to snapshot standby database
SQL> alter database convert to snapshot standby;
4. Recycle the database:
SQL> shutdown immediate
SQL> startup
SQL> select open_mode, database_role from v$database;
You can see database enable for read/write operations
5. Convert snapshot standby database back to physical standby database:
SQL> connect / as sysdba
SQL> shutdown immediate
SQL> startup mount
SQL> alter database convert to physical standby;
SQL> shutdown
Start managed recovery process:
SQL> alter database recover managed standby database disconnect;
SQL> select open_mode, database_role from v$database;
Subscribe to:
Posts (Atom)
