Thursday, December 8, 2011

Upgrading the Protection Mode and Downgrading the Protection Mode

Upgrading the Protection Mode
Use the following steps to upgrade the protection mode from the default of Maximum Performance.


Identify the current configuration:


Primary Database (TNS Service Name): TESTDB_VMLINUX3.IDEVELOPMENT.INFO
Standby Database (TNS Service Name): TESTDB_VMLINUX4.IDEVELOPMENT.INFO
Current Protection Mode: Maximum Performance mode using ARCH

Both of the higher protection modes (Maximum Availability and Maximum Protection) require the use of standby redo logs on the destination standby database. If standby redo logs do not exist for the standby database, create them now.

[Connect to the standby database]

SQL> connect sys/change_on_install@testdb_vmlinux4.idevelopment.info as sysdba

[Verify if using oracle managed files]

SQL> select value from v$parameter where name = 'db_create_online_log_dest_1';

VALUE
-------------------
/u02/oradata/TESTDB

[Do any standby redo logs exist on the standby database?]

SQL> select group#, bytes, 'online' as type from v$log
2 union
3 select group#, bytes, 'standby' as type from v$standby_log
4 order by 1;

GROUP# BYTES TYPE
---------- ---------- -------
1 104857600 ONLINE
2 104857600 ONLINE
3 104857600 ONLINE

[Need to first cancel Managed Recovery mode if it is running]

SQL> alter database recover managed standby database cancel;

[Create appropriate number standby redo log files on the standby database]

SQL> alter database add standby logfile group 4 size 100m;
SQL> alter database add standby logfile group 5 size 100m;
SQL> alter database add standby logfile group 6 size 100m;
SQL> alter database add standby logfile group 7 size 100m;

[Put standby database back into Managed Recovery mode]

SQL> alter database recover managed standby database disconnect from session;

[Verify new standby redo logs on standby database]

SQL> select group#, bytes, 'online' as type from v$log
2 union
3 select group#, bytes, 'standby' as type from v$standby_log
4 order by 1;

GROUP# BYTES TYPE
---------- ---------- -------
1 104857600 ONLINE
2 104857600 ONLINE
3 104857600 ONLINE
4 104857600 STANDBY
5 104857600 STANDBY
6 104857600 STANDBY
7 104857600 STANDBY



Ensure that the attributes for LOG_ARCHIVE_DEST_n are configured on the primary instance to support the desired protection mode. Also note that the destination standby database should be enabled to support the target protection mode as documented in this article.

For the mode of Maximum Protection, the standby database must be up and mounted!




Set the LOG_ARCHIVE_DEST_n initialization parameter on the primary database to support the required protection mode:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba

[Configure log transport services to support the desired protection mode]

SQL> alter system set log_archive_dest_2='service=testdb_vmlinux4.idevelopment.info LGWR SYNC AFFIRM';
SQL> alter system set log_archive_dest_state_2=enable;



The primary database will need to be closed and then placed in the MOUNT stage.

SQL> shutdown immediate
SQL> startup mount



On the primary database, change the protection mode and open the database:

For Maximum Protection mode:

SQL> alter database set standby database to maximize protection;
SQL> alter database open;



For Maximum Availability mode:

SQL> alter database set standby database to maximize availability;
SQL> alter database open;



Query the data dictionary on the primary database to verify the new protection mode:

SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, DATABASE_ROLE FROM V$DATABASE;

PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE
------------------- ------------------- --------------
MAXIMUM PROTECTION MAXIMUM PROTECTION PRIMARY



(Optional) Although the steps in this section are optional, there are highly recommended so that the primary database can easily and quickly switchover to a standby role without the need for DBA intervention. For example, standby redo logs are only used on the physical standby database; however, creating and having standby redo logs ready to go on the physical primary database makes role transition much easier if the primary would every have to become the standby:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba

[Do any standby redo logs exist on the primary database?]

SQL> select group#, bytes, 'online' as type from v$log
2 union
3 select group#, bytes, 'standby' as type from v$standby_log
4 order by 1;

GROUP# BYTES TYPE
---------- ---------- -------
1 104857600 ONLINE
2 104857600 ONLINE
3 104857600 ONLINE

[Create appropriate number standby redo log files on the primary database]

SQL> alter database add standby logfile group 4 size 100m;
SQL> alter database add standby logfile group 5 size 100m;
SQL> alter database add standby logfile group 6 size 100m;
SQL> alter database add standby logfile group 7 size 100m;

[Verify new standby redo logs on primary database]

SQL> select group#, bytes, 'online' as type from v$log
2 union
3 select group#, bytes, 'standby' as type from v$standby_log
4 order by 1;

GROUP# BYTES TYPE
---------- ---------- -------
1 104857600 ONLINE
2 104857600 ONLINE
3 104857600 ONLINE
4 104857600 STANDBY
5 104857600 STANDBY
6 104857600 STANDBY
7 104857600 STANDBY



Also, on the standby database(s), configure the LOG_ARCHIVE_DEST_n parameter attributes so the Data Guard configuration can continue to operate in the new protection mode after a switchover:

[Connect to the standby database]

SQL> connect sys/change_on_install@testdb_vmlinux4.idevelopment.info as sysdba

SQL> alter system set log_archive_dest_2='service=testdb_vmlinux3.idevelopment.info LGWR SYNC AFFIRM';
SQL> alter system set log_archive_dest_state_2=defer;



Downgrading the Protection Mode
Use the following steps to downgrade the protection mode from the current higher protection mode.


Identify the current configuration:


Primary Database (TNS Service Name): TESTDB_VMLINUX3.IDEVELOPMENT.INFO
Standby Database (TNS Service Name): TESTDB_VMLINUX4.IDEVELOPMENT.INFO
Current Protection Mode: Maximum protection using LGWR SYNC AFFIRM

Configure the attributes for LOG_ARCHIVE_DEST_n on the primary instance to support the new desired protection mode:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba

[Configure log transport services to support the desired protection mode]

SQL> alter system set log_archive_dest_2='service=testdb_vmlinux4.idevelopment.info ARCH';
SQL> alter system set log_archive_dest_state_2=enable;



Shutdown and mount the primary and standby database:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba
SQL> shutdown immediate
SQL> startup mount

[Connect to the standby database]

SQL> connect sys/change_on_install@testdb_vmlinux4.idevelopment.info as sysdba
SQL> alter database recover managed standby database cancel;
SQL> shutdown immediate
SQL> startup nomount
SQL> alter database mount standby database;



Downgrade the primary database to the desired protection mode:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba
[For Maximum Performance mode]

SQL> alter database set standby database to maximize performance;
[For Maximum Availability mode]

SQL> alter database set standby database to maximize availability;



Both of the higher protection modes (Maximum Availability and Maximum Protection) require the use of standby redo logs on the destination standby database. It you were to downgrade from Maximum Protection mode to Maximum Availability mode, you would need to keep the standby redo logs that exist for the standby database. If downgrading to Maximum Performance mode, you can drop the standby redo logs from the standby unless you are going to be configuring log transport services to use LGWR. For this example, I am going to be downgrading to maximum performance mode and using ARCH for log transport services and can therefore drop any standby redo logs from the standby database (and the primary if they exist):

[Connect to the standby database]

SQL> connect sys/change_on_install@testdb_vmlinux4.idevelopment.info as sysdba

[Drop any standby redo logs from the standby database]

SQL> alter database drop standby logfile group 4;
SQL> alter database drop standby logfile group 5;
SQL> alter database drop standby logfile group 6;
SQL> alter database drop standby logfile group 7;



If standby redo logs exist on the primary and you are downgrading to Maximum Performance mode, they can be removed:

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba

[Drop any standby redo logs from the primary database]

SQL> alter database drop standby logfile group 4;
SQL> alter database drop standby logfile group 5;
SQL> alter database drop standby logfile group 6;
SQL> alter database drop standby logfile group 7;



Put the standby database in managed recovery mode and open the primary database with the new protection mode enabled:

[Connect to the standby database]

SQL> connect sys/change_on_install@testdb_vmlinux4.idevelopment.info as sysdba
SQL> alter database recover managed standby database disconnect from session;

[Connect to the primary database]

SQL> connect sys/change_on_install@testdb_vmlinux3.idevelopment.info as sysdba
SQL> alter database open;



Query the data dictionary on the primary database to verify the new protection mode:

SQL> select protection_mode, protection_level, database_role from v$database;

PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE
-------------------- -------------------- --------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PRIMARY
Posted by at No comments:

Different kind of protection modes Oracle offers in a Data Guard Environment



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.

Posted by at No comments:

Tuesday, November 15, 2011

How to find log sequences used during the recovery 

RMAN> restore database preview;

Starting restore at 2009-MAY-22 11:24:50

using channel ORA_DISK_1

List of Backup Sets

===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time     

------- ---- -- ---------- ----------- ------------ --------------------

1       Full    209.16M    DISK        00:01:50     2009-MAY-22 11:21:04

        BP Key: 1   Status: AVAILABLE  Compressed: YES  Tag: TAG20090522T111914

        Piece Name: /u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_05_22/o1_mf_nnndf_TAG20090522T111914_51d6fm3b_.bkp

  List of Datafiles in backup set 1

  File LV Type Ckp SCN    Ckp Time             Name

  ---- -- ---- ---------- -------------------- ----

  1       Full 1621673    2009-MAY-22 11:19:15 /u01/app/oracle/oradata/ORCL/system01.dbf

  2       Full 1621673    2009-MAY-22 11:19:15 /u01/app/oracle/oradata/ORCL/sysaux01.dbf

  3       Full 1621673    2009-MAY-22 11:19:15 /u01/app/oracle/oradata/ORCL/undotbs01.dbf

  4       Full 1621673    2009-MAY-22 11:19:15 /u01/app/oracle/oradata/ORCL/users01.dbf



List of Archived Log Copies for database with db_unique_name ORCL

=====================================================================



Key     Thrd Seq     S Low Time            

------- ---- ------- - --------------------

30      1    97      A 2009-MAY-22 11:11:24

        Name: /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2009_05_22/o1_mf_1_97_51d6kvcr_.arc

Media recovery start SCN is 1621093

Recovery must be done beyond SCN 1621673 to clear datafile fuzziness

Finished restore at 2009-MAY-22 11:24:51

RMAN> exit





Recovery Manager complete.

How to find log sequences used during the recovery

From above restore preview, we confirm that all redo logs generated from SCN 1621093 and 1621673 will be used.

SQL> select thread#,sequence# from v$archived_log

  2  where --cross begin backup only (sample SEQ# 90)

  3  (first_change#<=1621093 and next_change#>=1621093 and next_change#<=1621673)

  4  or    --within begin backup and end backup (sample SEQ# 91,92)

  5  (first_change#>=1621093 and next_change#<=1621673)

  6  or   --cross end backup only (sample SEQ# 93)

  7  (first_change#>=1621093 and first_change#<=1621673 and next_change#>=1621673)

  8  or   --cross begin backup and end backup (sample SEQ# 150)

  9  (first_change#<=1621093 and next_change#>=1621673)

 10  ;



   THREAD#  SEQUENCE#

---------- ----------

         1         97
Posted by at No comments:

Oracle dba Interview Questions

Oracle dba Interview Questions --------------------à>>>>>>>>>

Because you did not perform the restore and recovery when connected to the recovery catalog, the recovery catalog contains no records for any of the restored files or the procedures performed during the test. Likewise, the control file of the trgta database is completely unaffected by the test.

Q-1: One of my control file corrupted and I am unable start database, How can I perform recovery?

If one of your control file is missing or corrupted then we have 2 options to recover it. Check alert.log for exact name and location of corrupted control file. Delete it manually and copy from available rest of control file and rename it and start database. Another option is delete corrupted control file and remove name from parameter file/ spfile. After removing said control file from spfile, start your database.

Q-2: What is incremental checkpoint?

In incremental checkpoint process, CKPT process records lowest Low RBA to the control file to keep advancing the Buffer checkpoint Queue (BCQ) to make easy and fastest Active Checkpoint Queue (ACQ).

Q-3: Does incremental checkpoint recorded in Alert.log? How to disable it?

We can enable disable recording incremental checkpoint in alert.log .We can enable/disable recording using parameter log_checkpoints_to_alert=true/false.

Q-4: I am working as Oracle DBA in 24/7 running large production database. Size of database is around 800 GB. We take hot backup every day night. But one day at around 4:00 PM, by mistake one table is dropped by application user. Table is very useful. How to recover that dropped table?

If your database is running on Oracle 10g version then there is new feature available called Recyclebin. You can recover dropped table from user_recyclebin or dba_recyclebin.

Q-5: In continuation of above scenario, No. Recyclebin doesn’t enable in my database then how to I recover my table in above scenario?

Then you should need to restore backup on your UAT or test database server and enable time based recovery for applying all archives before drop command execution. For an instance, apply archives up to 3:55 PM here.

Q-6: In continuation of above scenario, why I should need to perform recovery in UAT or test database server? Can I restore backup in production database server?

No. It is not recommended because your production database is large database and running 24/7 environment. Restoration and recovery will take downtime. It is better to perform restoration and recovery process on UAT or Test database.

Q-7: What is the meaning of LGWR SYNC and LGWR ASYNC in log archive destination parameter for standby configuration?

When use LGWR with SYNC, it means once network I/O initiated, LGWR has to wait for completion of network I/O before write processing. LGWR with ASYNC, means LGWR doesn’t wait to finish network I/O and continuing write processing.

Q-8: How can I know my require table is available in export dump file or not?

Create indexfile of export dump file using import with indexfile command. A text file will be generating with all table and index object name with number of rows. You can confirm your require table object from this text file.

Q-9: Archive log are being generated around 20 GB in my production large database. But one day almost double archives were generated. What is the reason behind this? How can I check it?

There are lots of reason behind increasing size of archives like If more database changes were performed using batch jobs or any special task like merging 2 database or data etc. You can check it using enabling Log Minor utility.

Q-10: How do you recover from the loss of datafile if the DB is running in ARCHIVELOG mode?

We can perform this recovery in 2 ways. One is open database mode and another is database mount mode. After taking offline lost datafile, we can bring database open and after that restore lost datafile from last backup. After restoration of datafile we can perform datafile level recovery for applying archive logs and make it online. In database mount mode, we can restore datafile from backup and perform datafile recovery using “Recover datafile” command.

Q-11: What is a Complete Recovery?

During this recovery we are applying all database changes using archives log and make it to up to date. Complete recovery can be done full database level or datafile level or tablespace level. Main concept is to apply all data changes using archive logs and bring database up to recent time.

Q-12: Why we should need to open database using RESETLOGS after finishing incomplete recovery?

When we are performing incomplete recovery it means we bring database to past time or rewind period of time using change based, cancel based or time based recovery. These all recovery make database in prior state of database. The forward sequence number already available after performing recovery, due to mismatching of this sequence numbers and prior state of database, it needs to open database with new sequence number of Redo log and archive logs.

Q-13: Why export backup called as logical backup?

Export dump file doesn’t backup or contain any physical structure of database like datafile, control file, redo log file, parameter file, password file. Instead of physical structure, export dump contains logical structure of database like definition of tablespaces, segments, schemas, data of segments etc. Due to these reasons export dump is called as logical backup.

Q-14: Have you faced any recovery scenario? Explain us how you resolved it?

2 months back, a potential table was dropped by an application developer on our large 24/7 running production database. Immediately he informed us. We have standby database for our production database. We checked that archives didn’t apply to standby database up to dropped timing. We stopped archive applying on standby immediately and open database read only. Took export of dropped table and imported in production database. After finishing appropriate checking of table, again we started archive applying in standby database for refreshing.

Q-15: Which command I should need to execute to take backup of database which is running on NOARCHIVELOG mode?

Shutdown immediate. Because without shutdown, we can’t perform online backup of database, which running on NOARCHIVELOG mode. We should need to take cold backup of database.

Posted by at No comments:

Sunday, November 6, 2011

Voting disk and OCR Management

Voting disk and OCR Management

The recommendations for the addition or removal of a voting disk is shutdown Oracle Cluster ware first on all nodes and then utilize the commands below as root user where path is completely qualified path for the additional voting disk. In the case of new voting disk over the network file system (NFS), create an empty voting disk file location with the correct owner and permissions before execute of commands mentioned below. Three extra raw partitions /dev/raw/raw3/, dev/raw/raw4, /dev/raw/raw5 have been created in order to practice following excercises

  • Run the following command to find path of voting disks

[oracle@crs1 ~]$ crsctl query css votedisk

0. 0 /dev/raw/raw2

located 1 votedisk(s).

  • Run the following command as the root user to add a voting disk

[root@crs1 oracle]# crsctl stop crs

[root@crs2 oracle]# crsctl stop crs

[root@crs1 oracle]# crsctl add css votedisk /dev/raw/raw3 -force

Now formatting voting disk: /dev/raw/raw3

successful addition of votedisk /dev/raw/raw3.

[root@crs1 oracle]# crsctl start crs

[root@crs2 oracle]# crsctl start crs

[oracle@crs2 oracle]$ crsctl query css votedisk

0. 0 /dev/raw/raw2

1. 0 /dev/raw/raw3

located 2 votedisk(s).

  • Run the following command as the root user to remove a voting disk

# crsctl delete css votedisk path

  • Backup and Recovery of Voting Disk

Back up the voting

dd if=voting_disk_name of=backup_file_name

[oracle@crs1 ~]$ dd if=/dev/raw/raw2 of=/home/oracle/backup/votdisk1

Recovering Voting Disks

dd if=backup_file_name of=voting_disk_name

  • Administering the Oracle Cluster Registry in Oracle Real Application Clusters

OCR file location is in following file

For Sun Solaris /var/opt/oracle/ocr.loc

For Linux /etc/oracle/ocr.loc

If OCR resides on a cluster, file system file or if the OCR is on a network file system, then create the target OCR file before adding OCR.

  • Use the OCRCHECK utility to verify the OCR integrity

The things displayed by OCRCHECK utility are – the version of the OCR’s block format; total space used and available; OCRID; and the OCR locations that have been configured. A block-by-block checksum operation for all of the blocks in all the configured OCRs is performed by OCRCHECK. It also returns an individual status for each file as well as a result for the overall OCR integrity check.

[root@crs1 oracle]# ocrcheck

Status of Oracle Cluster Registry is as follows :

Version : 2

Total space (kbytes) : 524184

Used space (kbytes) : 5644

Available space (kbytes) : 518540

ID : 87847809

Device/File Name : /dev/raw/raw1

Device/File integrity check succeeded

Device/File not configured

Cluster registry integrity check succeeded

Device/File not configured means ocrmirror is not configured

OCRCHECK creates a log file in the directory CRS_Home/log/hostname/client. To change amount of logging, edit the file CRS_Home/srvm/admin/ocrlog.ini.

  • Run the following command to add an OCR mirror location using either destination_file or disk to designate the target location of the additional OCR

First, make sure you have proper backup of ocr

[root@crs2 oracle]# ocrconfig –showbackup

  • Run the following command to add an OCR location using either destination_file or disk to designate the target location of the additional OCR

ocrconfig -replace ocr destination_file or disk

ocrconfig -replace ocrmirror destination_file or disk

First zero out the raw device

If your OCR configuration were altered while a particular node is stopped, you would be required to repair the OCR configuration on that particular node. For instance, there may be need to repair the OCR on a node that was not up at the time of removing, replacing or adding an OCR. For repairing an OCR configuration, run the following command on the node on which the Oracle Clusterware daemon was stopped.

ocrconfig –repair ocrmirror device_name

This operation only changes the OCR configuration on the node from which you run this command. For example, if the OCR mirror device name is /dev/raw1, then use the command syntax ocrconfig -repair ocrmirror /dev/raw1 on this node to repair its OCR configuration.

You cannot perform this operation on a node on which the Oracle Clusterware daemon is running.

  • Run the following command on any node in the cluster to remove the OCR

ocrconfig -replace ocr

  • Run the following command on any node in the cluster to remove the mirrored OCR

ocrconfig -replace ocrmirror

  • The above commands update the OCR configuration on all of the nodes on which Oracle Clusterware is running.
  • The ocrconfig Command Options
Option Purpose
-backuploc To change an OCR backup file location. For this entry , use a full path that is accessible by all of the nodes.
-downgrade To downgrade an OCR to an earlier version.
-export To export the contents of an OCR into a target file.
-help To display help for the ocrconfig commands.
-import To import the OCR contents from a previously exported OCR file.
-overwrite To update an OCR configuration that is recorded on the OCR with the current OCR configuration information that is found on the node from which you are running this command.
-repair To update an OCR configuration on the node from which you are running this command with the new configuration information specified by this command.
-replace To add, replace, or remove an OCR location.
-restore To restore an OCR from an automatically created OCR backup file.
showbackup To display the location, timestamp, and the originating node name of the backup files that Oracle created in the past 4 hours, 8 hours, 12 hours, and in the last day and week. You do not have to be the root user to execute the -showbackup option.
-upgrade To upgrade an OCR to a later version.

For example, to export the OCR contents to a binary file, use the ocrconfig command with the following syntax where file_name is the file to which you want to export the OCR contents as follows

ocrconfig -export file_name

  • Managing Backups and Recovering the OCR Using OCR Backup Files

This section explains the two methods for the purpose of copying of OCR content and further utilizing it for recovery. The first method uses automatically generated OCR file copies and the second method uses manually created OCR export files.

The Oracle Clusterware automatically creates OCR backups every four hours. At any one time, Oracle always retains the last three backup copies of the OCR. The CRSD process that creates the backups also creates and retains an OCR backup for each full day and at the end of each week.

Restoring the Oracle Cluster Registry on UNIX-Based Systems: use oracheck to check OCR status

Use the following procedure to restore the OCR on UNIX-based systems:

Identify the OCR backups using the ocrconfig -showbackup command. Review the contents of the backup using ocrdump -backupfile file_name where file_name is the name of the backup file.

Stop Oracle Clusterware on all of the nodes in your Oracle RAC database by executing the init.crs stop command on all of the nodes.

Perform the restore by applying an OCR backup file that you identified in Step 1 using the following command where file_name is the name of the OCR that you want to restore. Make sure that the OCR devices that you specify in the OCR configuration exist and that these OCR devices are valid before running this command.

ocrconfig -restore file_name

Restart Oracle Clusterware on all of the nodes in your cluster by restarting each node or by running the init.crs start command.

Run the following command to verify the OCR integrity where the -n all argument retrieves a listing of all of the cluster nodes that are configured as part of your cluster.

cluvfy comp ocr -n all [-verbose]

Use the OCRDUMP utility to write the OCR contents to a file so that you can examine the OCR content.

ocrdump [file_name|-stdout] [-backupfile backup_file_name] [-keyname keyname] [-xml] [-noheader]

OCRDUMP Options and Option Descriptions

Options Description
file_name Name of a file to which you want OCRDUMP to write output.
-stdout The predefined output location that you can redirect with, for example, a filename.
-keyname The name of an OCR key whose subtree is to be dumped.
-xml Writes the output in XML format.
-noheader Does not print the time at which you ran the command and when the OCR configuration occurred.
-backupfile Option to identify a backup file.
backup_file_name The name of the backup file the content of which you want to view. You can query the backups using the ocrconfig -showbackup command
  • OCR Exports/Imports

ocrconfig -export file_name

ocrconfig -import file_name

Restart Oracle Clusterware on all of the nodes in your cluster by restarting each node.

Run the following Cluster Verification Utility (CVU) command to verify the OCR integrity where the -n all argument retrieves a listing of all of the cluster nodes that are configured as part of your cluster:

cluvfy comp ocr -n all [-verbose]

Posted by at No comments:

Managing Data Guard using DGMGRL

Managing Data Guard using DGMGRL
  • Make dg_broker_start= TRUE on both primary (ocmdb) and secondary (phyocm) databases.

    • SQL> SHOW PARAMETER dg
    SQL> ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH;

  • Configure listener.ora for DGMGRL

These ‘_DGMGRL’ entries in the listener.ora files on each system are required for Broker operations invoked using DGMGRL that require connecting remotely to a database to function normally. Without them, the Broker cannot connect to the target database when it is down, as is the case in a switchover or failover or any other operation that requires a restart of a database.

As non-default port, local listener is used for ocmdb and phyocm. Add SID_DESC for DGMGRL for both Primary and Secondary on non-default port listener SID_LIST as mentioned in BOLD

SID_LIST_LISTENER_OCM =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ocmdb)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = ocmdb)
)
(SID_DESC =
(GLOBAL_DBNAME = ocmdb_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = ocmdb)
)
)

SID_LIST_LISTENER_PHYOCM =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = phyocm)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = phyocm)
)
(SID_DESC =
(GLOBAL_DBNAME = phyocm_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = phyocm)
)
)

  • Run “netmgr” and verify that the Oracle Net pre-requisites for using the DGMGRL command line interface have been satisfied.
  • Commands to get dgmgrl help

DGMGRL>help edit
DGMGRL>help remove
DGMGRL> help enable
DGMGRL> help start

  • DGMGRL Create Configuration

[oracle@ocm ~]$ dgmgrl

DGMGRL> connect sys@ocmdb

  • Create configuration with “ocmdb” as the Primary database. Add in the information about the physical standby database

DGMGRL> CREATE CONFIGURATION OCMDB AS PRIMARY DATABASE IS OCMDB
CONNECT IDENTIFIER IS OCMDB;
Configuration “ocmdb” created with primary database “ocmdb”

DGMGRL> ADD DATABASE phyocm AS CONNECT IDENTIFIER IS phyocm
MAINTAINED AS PHYSICAL;
Database “phyocm” added

DGMGRL> enable configuration;
Enabled.

DGMGRL> show configuration;
Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database

Current status for “ocmdb”:
SUCCESS

DGMGRL> show database verbose ocmdb ;
Database
Name: ocmdb
Role: PRIMARY
Enabled: YES
Intended State: ONLINE
Instance(s):
ocmdb

Properties:
InitialConnectIdentifier = ‘ocmdb’
LogXptMode = ‘ASYNC’
Dependency = ”
DelayMins = ’0′
Binding = ‘OPTIONAL’
MaxFailure = ’0′
MaxConnections = ’1′
ReopenSecs = ’300′
NetTimeout = ’180′
LogShipping = ‘ON’
PreferredApplyInstance = ”
ApplyInstanceTimeout = ’0′
ApplyParallel = ‘AUTO’
StandbyFileManagement = ‘AUTO’
ArchiveLagTarget = ’0′
LogArchiveMaxProcesses = ’2′
LogArchiveMinSucceedDest = ’1′
DbFileNameConvert = ”
LogFileNameConvert = ‘phyocm, ocmdb’
FastStartFailoverTarget = ”
StatusReport = ‘(monitor)’
InconsistentProperties = ‘(monitor)’
InconsistentLogXptProps = ‘(monitor)’
SendQEntries = ‘(monitor)’
LogXptStatus = ‘(monitor)’
RecvQEntries = ‘(monitor)’
HostName = ‘ocm.prusolutions.com’
SidName = ‘ocmdb’
LocalListenerAddress = ‘(ADDRESS=(PROTOCOL=TCP)(HOST=ocm.prusolutions.com)(PORT=2010))’
StandbyArchiveLocation = ‘location=use_db_recovery_file_dest’
AlternateLocation = ”
LogArchiveTrace = ’0′
LogArchiveFormat = ‘%t_%s_%r.dbf’
LatestLog = ‘(monitor)’
TopWaitEvents = ‘(monitor)’

Current status for “ocmdb”:
SUCCESS

  • Managing Databases using DGMGRL

You can view and change database properties using dgmgrl

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘ASYNC’

DGMGRL> show database ocmdb nettimeout;
NetTimeout = ’180′

DGMGRL> show database phyocm logxptmode;
LogXptMode = ‘ASYNC’

DGMGRL> show database phyocm nettimeout;
NetTimeout = ’180′

  • Using sqlplus connect to primary database and change value of log_archive_max_processes parameter

SQL> SHOW PARAMETER log_archive_max_processes;

The current value is two, increase it to five and again check database configuration from dgmgrl

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=5 SCOPE=MEMORY;

  • Use show configuration command to get Dataguard status

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database

Current status for “ocmdb”:
Warning: ORA-16608: one or more databases have warnings

  • Use show database verbose ocmdb to get ocmdb database details

DGMGRL> show database verbose ocmdb ;

Database
Name: ocmdb
Role: PRIMARY
Enabled: YES
Intended State: ONLINE
Instance(s):
ocmdb

Properties:
InitialConnectIdentifier = ‘ocmdb’
LogXptMode = ‘ASYNC’
Dependency = ”
DelayMins = ’0′
Binding = ‘OPTIONAL’
MaxFailure = ’0′
MaxConnections = ’1′
ReopenSecs = ’300′
NetTimeout = ’180′
LogShipping = ‘ON’
PreferredApplyInstance = ”
ApplyInstanceTimeout = ’0′
ApplyParallel = ‘AUTO’
StandbyFileManagement = ‘AUTO’
ArchiveLagTarget = ’0′
LogArchiveMaxProcesses = ’2′
LogArchiveMinSucceedDest = ’1′
DbFileNameConvert = ”
LogFileNameConvert = ‘phyocm, ocmdb’
FastStartFailoverTarget = ”
StatusReport = ‘(monitor)’
InconsistentProperties = ‘(monitor)’
InconsistentLogXptProps = ‘(monitor)’
SendQEntries = ‘(monitor)’
LogXptStatus = ‘(monitor)’
RecvQEntries = ‘(monitor)’
HostName = ‘ocm.prusolutions.com’
SidName = ‘ocmdb’
LocalListenerAddress = ‘(ADDRESS=(PROTOCOL=TCP)(HOST=ocm.prusolutions.com)(PORT=2010))’
StandbyArchiveLocation = ‘location=use_db_recovery_file_dest’
AlternateLocation = ”
LogArchiveTrace = ’0′
LogArchiveFormat = ‘%t_%s_%r.dbf’
LatestLog = ‘(monitor)’
TopWaitEvents = ‘(monitor)’

Current status for “ocmdb”:
Warning: ORA-16792: configuration property value is inconsistent with database setting

  • Get database inconsistent properties and fix the problem

DGMGRL> show database ocmdb inconsistentproperties;

INCONSISTENT PROPERTIES
INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE
ocmdb LogArchiveMaxProcesses 5 2 2

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=2 SCOPE=MEMORY;

DGMGRL> show database ocmdb inconsistentproperties;

INCONSISTENT PROPERTIES
INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database

Current status for “ocmdb”:
SUCCESS

  • Open new terminals connect to ocmdb and phyocm using sqlplus and execute following sql

SQL>SELECT db_unique_name,
database_role,
protection_mode,
protection_level
FROM v$database;

  • Edit Database property using DG Broker

DGMGRL> edit database ocmdb set property LogArchiveMaxProcesses=10;
Property “logarchivemaxprocesses” updated

DGMGRL> edit database ocmdb set property LogArchiveMaxProcesses=10;
Property “logarchivemaxprocesses” updated

  • Change configuration set Protection Mode to MaxAvailability from MaxPerformance

When you try to change set Protection Mode to MaxAvailability, it will give error, as Standby database phyocm property logxptmode is ‘ASYNC’

DGMGRL> edit configuration set protection mode as maxavailability;
Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode
Failed.

Check database property logxptmode

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘ASYNC’

DGMGRL> show database phyocm logxptmode;
LogXptMode = ‘ASYNC’

Change LogXptMode to SYNC of Physical Standby database PHYOCM ONLY and then change the protection mode

DGMGRL> edit database phyocm set property logxptmode=’SYNC’;
Property “logxptmode” updated

DGMGRL> show database phyocm logxptmode;
LogXptMode = ‘SYNC’

DGMGRL> edit configuration set protection mode as maxavailability;
Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.

Now change the property LogXptMode of ocmdb database to ‘SYNC’

DGMGRL> edit database ocmdb set property logxptmode=’SYNC’;
Property “logxptmode” updated

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘SYNC’

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: DISABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database

Current status for “ocmdb”:
SUCCESS

  • If due to some reason, the Dataguard Protection modes is not change to MaxAvailability using DGMGRL then do it from SQLPLUS

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

  • Open new terminals connect to ocmdb and phyocm using sqlplus and execute following sql

SQL>SELECT db_unique_name,
database_role,
protection_mode,
protection_level
FROM v$database;

  • Switch Over to Standby database phyocm

DGMGRL> switchover to phyocm;
Performing switchover NOW, please wait…
Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance “phyocm” on database “phyocm”
Shutting down instance “phyocm”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.
Operation requires startup of instance “phyocm” on database “phyocm”
Starting instance “phyocm”…
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is “phyocm”

If instances are down start them in mount mode, the primary database will automatically open

SQL> STARTUP MOUNT;

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: DISABLED
Databases:
ocmdb – Physical standby database
phyocm – Primary database

Current status for “ocmdb”:
SUCCESS

Open new terminals connect to ocmdb and phyocm using sqlplus and execute following sql

SQL>SELECT db_unique_name,
database_role,
protection_mode,
protection_level
FROM v$database;

  • Switchover back to ocmdb

DGMGRL> switchover to ocmdb;

DGMGRL> show configuration;

SQL>SELECT db_unique_name,
database_role,
protection_mode,
protection_level
FROM v$database;

  • Failover to phyocm

From sqlplus shutdown, abort primary database

[oracle@ocm ~]$ echo $ORACLE_SID
ocmdb

SQL> SHUTDOWN abort;

  • Using dgmgrl connect to new phyocm

[oracle@ocm ~]$ dgmgrl sys/oracle@phyocm

DGMGRL> failover to phyocm;

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ocmdb – Physical standby database (disabled)
phyocm – Primary database

Current status for “ocmdb”:
SUCCESS

  • The Protection Mode automatically goes back to MaxPerformance, but the logxptmode properties remains ‘SYNC’

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘SYNC’

DGMGRL> show database phyocm logxptmode;
LogXptMode = ‘SYNC’

  • Open a new terminal and set ORACLE_SID for phyocm

[oracle@ocm scripts]$ export ORACLE_SID=phyocm

SQL>SELECT db_unique_name,
database_role,
protection_mode,
protection_level
FROM v$database;

  • Connect to ocmdb and startup database in mount state

SQL> STARTUP mount;

  • Now reinstate database ocmdb as physical standby

DGMGRL> reinstate database ocmdb;
Reinstating database “ocmdb”, please wait…
Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.
Continuing to reinstate database “ocmdb” …
Reinstatement of database “ocmdb” succeeded

If reinstate fails for first time again start ocmdb database in mount state and reinstate, it will succeed in second or third attempt.

  • Switchover back to ocmdb to make ocmdb as Primary Database

DGMGRL> switchover to ocmdb;

Performing switchover NOW, please wait…
Operation requires shutdown of instance “phyocm” on database “phyocm”
Shutting down instance “phyocm”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “phyocm” on database “phyocm”
Starting instance “phyocm”…
ORACLE instance started.
Database mounted.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is “ocmdb”

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database

Current status for “ocmdb”:
SUCCESS

  • Fast Start Failover

Connect to physical standby using dgmgrl

[oracle@ocm ~]$ dgmgrl sys/oracle@phyocm

  • Currently the Protection Mode is MaxPerformance, For fast start failover the Protection Mode should be MaxAvailability.

    • Anytime to change configuration to “MaxAvailability” make sure the primary database property is logxptmode is “ASYNC” and standby database “logxptmode” is “SYNC then only it can be changed to “MaxAvailability” otherwise it will fail. If maxavailability does not work with DGMGRL then you do it from SQLPLUS

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

DGMGRL> show database phyocm logxptmode;
LogXptMode = ‘SYNC’

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘SYNC’

DGMGRL> edit database ocmdb set property logxptmode=’ASYNC’;
Property “logxptmode” updated

DGMGRL> show database ocmdb logxptmode;
LogXptMode = ‘ASYNC’

DGMGRL> edit configuration set protection mode as maxavailability;

Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.
Now make primary database “logxptmode” is “SYNC
DGMGRL> edit database ocmdb set property logxptmode=’SYNC’;
Property “logxptmode” updated

  • Make sure both primary and secondary databases have FLASHBACK ON

SQL> SELECT db_unique_name,
database_role,
open_mode,
flashback_on
FROM v$database;

  • Edit database property faststartfailovertarget and enable fast_start failover

DGMGRL> edit database phyocm set property faststartfailovertarget=ocmdb;
Property “faststartfailovertarget” updated

DGMGRL> edit database ocmdb set property faststartfailovertarget=phyocm;
Property “faststartfailovertarget” updated

DGMGRL> enable fast_start failover;
Enabled.

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database
– Fast-Start Failover target

Current status for “ocmdb”:
Warning: ORA-16608: one or more databases have warnings

DGMGRL> show database verbose ocmdb;

You will see warning in the end mentioned below

Current status for “ocmdb”:
Warning: ORA-16819: Fast-Start Failover observer not started

  • Connect to ocmdb using sqlplus and execute following commands

SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold
FROM v$database;

SQL> SELECT fs_failover_observer_present, fs_failover_observer_host
FROM v$database;

Now go to FSFO Observer window and start it >it is best recommended to use the ‘-logfile’ qualifier on the DGMGRL command to direct any of its output message to a file that can be examined in case of a problem. Additionally it is also suggested to specify unique data file name that Observer uses. This can be done by adding the ‘FILE=’ command to the ‘start observer’ command.

This will also allow you to start multiple Observers for multiple Primary/Standby pairs on the same Observer system using the same Oracle Home. In this example, since everything is on the same system, the log in was made using the current ORACLE_SID, which was setup to be the standby database phyocm. In a real setup neither of your databases should be on the Observer system so you would have to use the ‘@tnsname’ qualifier on the ‘sys/password’ login

[oracle@ocm ~]$ export ORACLE_SID=phyocm

[oracle@ocm ~]$ echo $ORACLE_SID
phyocm

[oracle@ocm ~]$ dgmgrl -logfile $ORACLE_HOME/rdbms/log/dgmgrlOCMDB.LOG sys/oracle
DGMGRL for Linux: Version 10.2.0.1.0 – Production

Copyright (c) 2000, 2005, Oracle. All rights reserved.

Welcome to DGMGRL, type “help” for information.
Connected.

DGMGRL> start observer file=’/u01/app/oracle/afoocmdb.dat’;

Make sure to correct observer file correctly having “afo.dat” in start

Connect to ocmdb using sqlplus and execute following commands
SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold
FROM v$database;

FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD
——————— —————————— ———————
SYNCHRONIZED phyocm 30

SQL> SELECT fs_failover_observer_present, fs_failover_observer_host
FROM v$database;

FS_FAIL FS_FAILOVER_OBSERVER_HOST
——- —————————————-
YES ocm.prusolutions.com

  • Open a new session using dgmgrl and connect to standby database phyocm

[oracle@ocm ~]$ dgmgrl sys/oracle@phyocm
DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ocmdb – Primary database
phyocm – Physical standby database
– Fast-Start Failover target

Current status for “ocmdb”:
SUCCESS

  • Connect to ocmdb database and shutdown abort;

SQL> SHUTDOWN abort;
ORACLE instance shut down.

OR

$ps –ef | grep –i pmon

Kill pmon process to primary database ocmdb to failover

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ocmdb – Physical standby database (disabled)
– Fast-Start Failover target
phyocm – Primary database

Current status for “ocmdb”:
Warning: ORA-16608: one or more databases have warnings

DGMGRL> show database ocmdb;

Database
Name: ocmdb
Role: PHYSICAL STANDBY
Enabled: NO
Intended State: ONLINE
Instance(s):
ocmdb

Current status for “ocmdb”:
Error: ORA-16661: the standby database needs to be reinstated

  • Connect to ocmdb instance and startup

[oracle@ocm ~]$ export ORACLE_SID=ocmdb

[oracle@ocm ~]$ sqlplus / as sysdba

SQL> STARTUP;
ORACLE instance started.

Total System Global Area 536870912 bytes
Fixed Size 1220460 bytes
Variable Size 209715348 bytes
Database Buffers 314572800 bytes
Redo Buffers 11362304 bytes
Database mounted.
ORA-16649: database will open after Data Guard broker has evaluated Fast-Start
Failover status

  • It will take few minutes to get database synchronized. Execute following sql on both primary and secondary.

SQL> SELECT db_unique_name, open_mode, database_role FROM v$database;

SQL> SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold
FROM v$database;

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
ocmdb – Physical standby database
– Fast-Start Failover target
phyocm – Primary database

Current status for “ocmdb”:
SUCCESS

DGMGRL> STOP OBSERVER;
Done.

DGMGRL> disable fast_start failover;
Disabled.

DGMGRL> show configuration;

Configuration
Name: ocmdb
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: DISABLED
Databases:
ocmdb – Physical standby database
phyocm – Primary database

Current status for “ocmdb”:
SUCCESS

  • Switchover back to ocmdb

DGMGRL> switchover to ocmdb;

Performing switchover NOW, please wait…
Operation requires shutdown of instance “phyocm” on database “phyocm”
Shutting down instance “phyocm”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance “ocmdb” on database “ocmdb”
Shutting down instance “ocmdb”…
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance “phyocm” on database “phyocm”
Starting instance “phyocm”…
ORACLE instance started.
Database mounted.
Operation requires startup of instance “ocmdb” on database “ocmdb”
Starting instance “ocmdb”…
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is “ocmdb”

Posted by at No comments:
Subscribe to: Posts (Atom)