By Rene Kundersma on Apr 22, 2014
Read this new white paper to learn how to deploy and optimize Database-as-a-Service using Oracle Multitenant and Oracle MAA.
Join this online forum to hear from analysts and experts on how companies are beginning to transform with DBaaS, and learn the prescriptive steps your organization can take to design, deploy, and deliver DBaaS today.
Monday, October 21, 2013
9 a.m.–12 p.m PT / 12 p.m.–3 p.m. ET
Together with two colleagues from the MAA team I will be doing a presentation on consolidation for Oracle Exadata:
Title: Consolidation and Virtualization on Oracle Exadata: How, What, Where, and When (CON8530)
Abstract: How is database consolidation done on Oracle Exadata? This technical session looks at the past, present, and future consolidation solutions on Oracle Exadata. It describes all the consolidation options on Oracle Exadata, when to choose which, and the best practices for deploying an Oracle Database instance with each one
When: Monday, Sep 23, 3:15 PM - 4:15 PM - Westin San Francisco - Metropolitan I
Today I received the news a new demo has been made available on OTN for Data Guard protection from lost-write corruption. Since this is a typical MAA solution and a very nice demo I decided to mention this great feature also in this blog even while it's a recommended best practice for some time.
When lost writes occur an I/O subsystem acknowledges the completion of the block write even though the write I/O did not occur in the persistent storage. On a subsequent block read on the primary database, the I/O subsystem returns the stale version of the data block, which might be used to update other blocks of the database, thereby corrupting it. Lost writes can occur after an OS or storage device driver failure, faulty host bus adapters, disk controller failures and volume manager errors.
In the demo a data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, while in fact the write did not occur in the persistent storage. When a primary database lost write corruption is detected by a Data Guard physical standby database, Redo Apply (MRP) will stop and the standby will signal an ORA-752 error to explicitly indicate a primary lost write has occurred (preventing corruption from spreading to the standby database).
This post is about upgrades. The first thing I like to mention is the availability of 18.104.22.168 for the Oracle Exadata Database Machine since today (Jan 3rd 2012). With this, it is now possible to upgrade your Oracle Exadata Database Machine to 22.214.171.124. To help you best with the upgrade we have released a MOS note that describes the prerequisites and steps to go from 126.96.36.199 or 188.8.131.52 installations to 184.108.40.206. Please see the MOS note for the best approach on how to apply this upgrade in your environment. The MOS note applies to both Solaris 11 Express and Linux installations and upgrades both the Grid Infrastructure and the Database Home on V2, X2-2 and X2-8.
Please see MOS note "220.127.116.11/18.104.22.168 to 22.214.171.124 Database Upgrade on Exadata Database Machine" (Doc ID 1373255.1) for more details.
For V1 users we have recently also published MOS note 888834.1. This document contains the steps to upgrade the HP Oracle Database Machine to Oracle Exadata Storage Server Software 11.2.X. The steps include upgrading Oracle Cluster Ready Services (CRS) 126.96.36.199.X and Oracle Automatic Storage Management (ASM) 188.8.131.52.X to Oracle Grid Infrastucture 184.108.40.206 and Oracle RDBMS from 220.127.116.11 to Oracle RDBMS 18.104.22.168. After upgrading to 11.2.0 on V1 hardware using MOS note 888834.1, MOS note 1373255.1 can be used to upgrade to 22.214.171.124.
Please See MOS note "HP Oracle Database Machine 11.2 Upgrade" (Doc ID 888834.1)
Blog of Rene Kundersma, Principal Member of Technical Staff at Oracle Development USA. I am designing and evaluating solutions and best practices around database MAA focused on Exadata. This involves HA, backup/recovery, migration and database consolidation and upgrades on Exadata. Opinions are my own and not necessarily those of Oracle Corporation. See http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm.