Sync time

Windows 2000/XP's W32Time Service

The following example will make ntp1.example.local and ntp2.example.local our two synchronization sources (the quotes are only required when you have more than one server in your list).

net time /setsntp:"ntp1.example.local ntp2.example.local"

Now we need to start the "Windows Time" (W32Time) service. Open a command prompt (Click Start, then Run, type "cmd" and click ok.) and issue the following command:

net start "windows time"

net time [\\ComputerName] [/querysntp] [/setsntp[:NTPServerList]]
Parameters
file://ComputerName/ : Specifies the name of a server you want to check or with which you want to synchronize.
/set : Synchronizes the computer's clock with the time on the specified computer or domain.
/setsntp[:NTPServerList] : Specifies a list of NTP time servers to be used by the local computer. The list can contain IP addresses or DNS names, separated by spaces. If you use multiple time servers, you must enclose the list in quotation marks.

Check the list of time servers here
http://ntp.isc.org/bin/view/Servers/NTPPoolServers




Sync Time on Linux
# rdate -s time.nist.gov

Data Guard Broker thru CLI

The Data Guard broker is a centralized framework that creates, automates, and manages all aspects of a Data Guard configuration. This broker can be accessed locally or remotely by using either of the two clients: the command-line interface (CLI) or the Data Guard page of the new OEM. Once you are connected, you have the ability to change any attribute of the configuration as well as monitor progress and perform health checks.

The CLI Interface
We need to satisfy a few requirements. First, the physical or logical standby must have been created, as the CLI does not have the ability to create a standby (only the Data Guard GUI does). In addition, both the primary and standby databases must have been started with the DG_BROKER_START parameter equal to True (this spawns the DMON process) and be using an spfile.

init need to add
*.DG_BROKER_START=TRUE
*.FAL_CLIENT='ORCL1'
*.FAL_SERVER='ORCL2'
*.STANDBY_FILE_MANAGEMENT='AUTO'

c:> dgmgrl
DGMGRL> connect sys/password

DGMGRL> create
configuration 'MyDR' as
>primary database is 'orcl1'
>connect identifier is orcl1;

DGMGRL> add database 'orcl2' as
>connect identifier is orcl2
>maintained as physical;

DGMGRL> enable configuration;

DGMGRL> show configuration;

how to change the standby of the physical standby to the read-only mode for reporting purposes

DGMGRL> edit database 'orcl2' set state='READ-ONLY';

To return the physical standby to the recovery mode, we change the state once again.

DGMGRL> EDIT DATABASE 'orcl2' SET STATE='ONLINE';

DGMGRL> SWITCHOVER TO "ORCL2";

Use the SHOW DATABASE VERBOSE command to check the state, health, and properties of the primary database, as follows:

DGMGRL> SHOW DATABASE VERBOSE 'db01';

Performing a Failover Operation

You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable.

Connect to the target standby database.
To perform the failover operation, you must connect to the standby database to which you want to fail over using the SYSDBA username and password of that database. For example:

DGMGRL> CONNECT sys/oracle@db02

Issue the failover command.
Now you can issue the failover command to make the target standby database the new primary database for the configuration. Note that after the failover completes, the original primary database cannot be used as a viable standby database of the new primary database unless it is re-created as described in Section 4.2. T

DGMGRL> FAILOVER TO "DB02"

Some Data Guard links
http://www.dbasupport.com/oracle/ora10g/logical_standby_db.shtml
http://www.pafumi.net/Standby_Concepts_Configuration.html
http://www.oracle-base.com/articles/9i/DataGuard.php

Some Rman links
http://www.radford.edu/~wkantsio/oracle/rman-clone-win.htm

Manual Recovery - control files, redo log,etc

Recovering from Loss of a Control File

Losing one of the multiplexed control files immediately aborts the instance.
If you have not lost every control file, recovering from this failure is fairly straightforward.

SQL> startup nomount
SQL> select name, value from v$spparameter2 where name = 'control_files';

In the next step, you change the value of CONTROL_FILES in the SPFILE and restart theinstance, as you can see here:
SQL> alter system
set control_files ='/u02/oradata/ord/control01.ctl',
'/u06/oradata/ord/control02.ctl'4 scope = spfile;
SQL> shutdown immediate
SQL> startup

Recovering from Loss of a Redo Log File

A database instance stays up as long as at least one member of a redo log group is available. The alert log records the loss of a redo log group member.

1. Verify which redo log file group member is missing.
2. Archive the log file group’s contents; if you clear this log file group before archiving it, youmust back up the full database to ensure maximum recoverability of the database in the caseof the loss of a datafile. Use the command ALTER SYSTEM ARCHIVE LOG GROUP groupnum; toforce the archive operation.
3. Clear the log group to re-create the missing redo log file members using the command ALTER DATABASE CLEAR LOGFILE GROUP groupnum; you can also replace the missing member by copying one of the good group members to the location of the missing member

SQL> select * from v$logfile order by group#;
SQL> alter system archive log group 1;
SQL> alter database clear logfile group 1;
SQL> select * from v$logfile order by group#;