Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backups

April 14, 2013 by Leave a Comment

Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backups [ID 1389592.1]

What does this mean?  It means we can perform migrations from AIX/Solaris/HP-UX to Linux with significantly reduced downtime.  I can perform incremental backups across endianness.

This was originally tested for the Exadata and now it is available for everyone.


Posted by Charles Kim, Oracle ACE Director

Filed under Data Guard, Exadata, General DBA, RMAN

Data Guard Delay

April 14, 2013 by Leave a Comment

From time to time, customers ask if we can delay apply of archive logs on the standby database(s).  I tell them absolutely but MAA best practice is to setup flashback recovery area and enable database flashback on both the primary and physical standby databases.  In addition to enabling flashback, some customers are still persistent about delaying the apply on the physical standby database.  In physical standby, we can delay redo apply in one of two ways:

1.  alter database recover managed standby database using current logfile DELAY 30 disconnect;

2.  alter system set log_archive_dest_2=’SERVICE=###_PRIMARY_DATABASE_###_STDBY lgwr async reopen=30 delay=30 ….’ 

The delay attribute specifies that the archive logs are not available for recovery until the delay time interval has expired.  The delay option specifies the lag between when redo data is archived on a standby site and when the archived redo log file is applied to the standby database.  Important thing to note is that the delay does not impact the transmit time to the standby site.

 

Posted by Charles Kim, Oracle ACE Director

Filed under Data Guard

Viscosity Has 10 presentations at IOUG Collaborate 2013

February 10, 2013 by Leave a Comment

We will post the 10th session shortly …

Session #

Title

Room Assignment and Time

604

Rolling your own Database Operations Center (DOC) using Oracle Technology you already own

Mile High Ballroom 2A => Mon, Apr 08, 2013 (09:45 AM – 10:45 AM)

344

Performance Tuning your DB Cloud in OEM 12c Cloud Control – 360 Degrees

Mile High Ballroom 4A  => Mon, Apr 08, 2013 (09:45 AM – 10:45 AM)

614

Automate Data Guard Best Practices

Mile High Ballroom 2B => Mon, Apr 08, 2013 (05:00 PM – 06:00 PM)

 

 

 

477

Why Every Database Needs to be Virtualized

Mile High Ballroom 4A => Tue, Apr 09, 2013 (12:00 PM – 12:30 PM)

343

Oracle VM, OEM 12c and Cloud Computing:  Panel of Experts

C#13 vSIG Meeting => Tue, Apr 09, 2013 (4:15 PM – 5:15 PM)

 

 

 

441

ASM New Features – The New ASM Frontier

Mile High Ballroom 2C => Wed, Apr 10, 2013 (08:15 AM – 09:15 AM)

414

Engineered Systems Curriculum: The Perfect Marriage: ZFS Storage Appliance with Exadata

Mile High Ballroom 1C => Wed, Apr 10, 2013 (11:00 AM – 12:00 PM)

783

Virtualized Oracle Stretched RAC Cluster using VMware vSphere and EMC VPLEX

Mile High Ballroom 2A => Wed, Apr 10, 2013 (04:15 PM – 05:15 PM)

 

 

 

757

From Big Data to Exadata: The Best of Both Worlds for Business Analytics

Mile High Ballroom 1B => Thu, Apr 11, 2013 (09:45 AM – 10:45 AM)

 

 

 

Filed under ASM, Data Guard, Exadata, Linux, RAC, ZFSSA

IOUG 2013 Data Guard Best Practices Abstract Accepted

December 17, 2012 by Leave a Comment

Session Title: Automate Data Guard Best Practices
Session Number: 614
Track: Database
Session Type: Lecture
Sub-Categorization: High Availability and Data Protection
Initial Submission: Oct 12, 2012 11:32 AM America/Arizona
Status: Submitted
Session Submitter: Charles Kim
Primary Presenter: Charles Kim [Oracle ACE Director - Viscosity North America]
Co-Presenter: Nitin Vengurlekar [CTO - Viscosity North America]
Co-Presenter 2: [Unassigned]
Co-Presenter 3: [Unassigned]
Last Update: Oct 12, 2012 11:58 AM America/Arizona
   
Abstract: Compliance to industry best practices can easily be achieved with automation. This session will disseminate fundamental Data Guard best practices and demonstrate how DBAs can automate setup, configuration, and monitoring of Data Guard environments with assistance from the Date Guard Toolkit (DG Toolkit).

The original Data Guard Menu (DG Menu) was presented and documented in the Oracle Data Guard 11g Handbook published with Oracle Press. We took the DG Menu to another level and now it is called the DG Toolkit. We included a dedicated set of options for building physical standby with best practices in mind and made this into a mature toolkit that anyone can download from http://dataguardbook.com website. We have significantly updated the monitoring and setup menu options as well.

Come see Data Guard best practices in action. The session concentrates on:
o Building the Physical Standby
o Monitoring and Maintaining the Physical Standby
o Configuring Data Guard Broker
o Performing Backup and Recovery with RMAN
o Setting Archive Retention
o Performing Switchovers and Failovers
   
Learning Objective #1: Most importantly, learn how to build the physical standby with ease and automation using the DG Toolkit
Learning Objective #2: Learn how to monitor the physical standby database with DG Toolkit
Learning Objective #3: Learn how to setup the Data Guard Broker with DG Toolkit
Outline / Content Structure: Perform preliminary check prior to starting the Data Guard Build
1. Perform assessments on the source database
2. Perform assessments on the physical standby

Perform detailed steps to build the physical standby database
1. Look at building the physical standby with easy menu steps
2. Look at duplicating the physical standby database

Configure the Data Guard Broker

Perform monitoring of the Data Guard Environment
1. Monitor the physical standby for performance
2. See how far behind we are

Perform RMAN to disk configuration options

# ————————————————————————- #
# Data Guard Menu System #
# Primary Host: prod1 Standby Host: drdb1 #
# Primary DB: DBATOOLS Standby DB: DRDBATOOLS #
# ————————————————————————- #
# 10. Launch Preliminary Check Submenu #
# ————————————————————————- #
# 20. Launch Build Standby Database Submenu #
# ————————————————————————- #
# 30. Launch the Data Guard Broker Submenu #
# ————————————————————————- #
# 40. Launch Monitor Physical Standby Data Guard Submenu #
# ————————————————————————- #
# 50. Launch Monitor Logical Standby Data Guard Submenu #
# ————————————————————————- #
# 60. Launch Automatic Diagnostic Repository (ADR) CLI Submenu #
# ————————————————————————- #
# 100. Launch RMAN Backup to Disk Submenu #
# ————————————————————————- #
# x. Exit #
# ————————————————————————- #
2nd Track: Manageability
Content Level: Mid-Level
Product Line: Active Data Guard, Oracle Database, Real Application Clusters
Company Type: Consultant
Have you presented at an IOUG event before?: Yes
Speaker Guidelines: Yes 

Filed under Data Guard, Uncategorized

Viscosity North America

December 8, 2012 by Leave a Comment

VNA Core Competencies

Viscosity’s Core Competency centers arounds Oracle Real Application Clusters (RAC).   Because we are the top Oracle RAC Experts, we intimately know storage architecture, network infrastructure, operating systems, and most importantly, Oracle RAC database interactions within the ecosystem.  

Viscosity was formed by former Oracle Employees each of which worked in various capacities within Oracle Corporation. These capacities include Oracle Database, RAC Development, Oracle Consulting and Oracle Technical Architects, Design and Performance Tuning experts.

I am a co-founder and President of Viscosity North America, an Oracle ACE Director, an Oracle Certified DBA, Certified RAC Expert and a VMware Certified Professional. I specialize in Exadata, RAC, and Virtualization (VMware and Oracle VM) and authored three books: Oracle Database 11g New Features for DBA and Developers, Linux Recipes for Oracle DBAs and Oracle Data Guard 11g Handbook. I hold certifications in Oracle, VMware, Red Hat Linux, and Microsoft and has over 20 years of Oracle experience. I’ve sat on the panel of experts at VM World and Oracle OpenWorld for virtualization and Linux. I was one of the founding members of the IOUG virtualization SIG that launched in 2011 at Oracle OpenWorld.

If you look at the core of our competencies, we focus on what we are best at …  RAC.  RAC experts are expected to have in-depth knowledge in networks, clustering, storage, and operating systems.  Several of the managing directors have served as system administrators in past lives and hold specialized certifications in flavors of Unix.  

Because we know RAC, we know infrastructure.  Because we know infrastructure, we’ve adjusted our focus to the world of Database Cloud.  Not only do we adopt Oracle’s consolidation theme with Oracle RAC, we are heavily invested in VMware and Oracle VM.  Several of the managing directors at Viscosity hold certifications on VMware.  

Another area of mastery that we have taken is in the world of Exadata and Oracle engineered systems.  Not only are we the experts in Exadata implementation and performance tuning, we are also experts inother engineered systems such as the ZFS Storage Appliance and Oracle Database Appliance.

Viscosity’s Oracle Center of Expertise has developed best practices and tight partner relationships to implement world-class solutions. Our vast experience and intellectual property give customers insight into what is driving IT complexity. We can deliver a set of practical executable plans for simplifying IT infrastructure, helping reduce operating costs while freeing up resources for new business initiatives.

 

Filed under ASM, Data Guard, Exadata, Linux, RAC, RMAN

Delete Archivelogs in Data Guard After Archivelogs are Shipped to the Standby Site

October 13, 2012 by Leave a Comment

RMAN> show all;

RMAN configuration parameters for database with db_unique_name NRSP are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/product/11.2.0/db/dbs/snapcf_NRSP1.f’; # default

RMAN> configure archivelog deletion policy to shipped to all standby;

old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
new RMAN configuration parameters are successfully stored

Filed under Data Guard Tagged with

Flash Recovery Area (FRA)

July 15, 2011 by Leave a Comment

As a general rule, configure the FRA and define your local archiving parameters to be:

 
LOG_ARCHIVE_DEST_1=’LOCATION=USE_DB_RECOVERY_FILE_DEST’

As part of best practices, you should always enable Flashback Database on primary and standby databases for easy re-instantiation after a failover. With Flashback Database enabled, you do not have to rebuild the primary database after a database failover. You can re-instate the failed primary database. Also Flashback Database provides the mechanism to expeditiously rewind the database after an erroneous batch update, a bad data load, user error(s), or a malicious set of activities on the database.

Oracle MAA recommends that DB_FLASHBACK_RETENTION_TARGET should be set to a minimum of 60 minutes if all you are trying to achieve re-instantiation of the primary database after a failover; however, if you require the additional protection from user errors and corruptions, then you will need to extend that time. Oracle MAA best practices recommend a minimum of 6 hours retention period. You need to determine what that retention period is based on your business requirements. The longer you set the flashback retention time, more disk space you will need.

You should also enable Flashback Database on the standby database to minimize downtime resulting from logical corruptions.

Posted by Charles Kim, Oracle ACE Director

Filed under Data Guard, RAC

IOUG 2011 Data Guard Best Practices White Paper

July 14, 2011 by Leave a Comment

Here’s the link to my white paper on Automating Data Guard Best Practices

While you are there, you might as also download the Step-By-Step Cookbook Approach paper on building a physical standby database.

Created by Charles Kim, Oracle ACE Director

Filed under Data Guard Tagged with