Comments on: Exadata Diskgroup Planning http://blog.oracle-ninja.com/2011/12/exadata-diskgroup-planning/?utm_source=rss&utm_medium=rss&utm_campaign=exadata-diskgroup-planning Andy Colvin's Oracle Blog Tue, 07 May 2013 18:45:01 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: Andy Colvin http://blog.oracle-ninja.com/2011/12/exadata-diskgroup-planning/#comment-1049 Andy Colvin Mon, 17 Dec 2012 18:24:02 +0000 http://blog.oracle-ninja.com/?p=334#comment-1049 Vin,

The reason that each cell is a failgroup unto itself it to ensure that no 2 copies of data are placed on the same cell. If you had both copies of a block in a normal redundancy diskgroup on one cell and it went offline, the entire diskgroup would be offline until that cell came back.

If you’re planning on performing rolling cell patches, I would strongly advise to use high redundancy on your diskgroups, so that while you are degrading your mirror, the loss of a single disk during the process would not take you offline.

]]> By: Vinit http://blog.oracle-ninja.com/2011/12/exadata-diskgroup-planning/#comment-1048 Vinit Sun, 16 Dec 2012 16:32:59 +0000 http://blog.oracle-ninja.com/?p=334#comment-1048 Andy, Good write up on Disk group planning. We recently acquired an Exadata 2-2 Quarter Rack and was under the same dilemma – will the default disk groups (data, reco and dbfs_dg) be sufficient especially if we’re going to consolidate ?
However, my concern was on the design of the grid disks. Some of the grid disks fall under the same failure group within the same cell. What that means is during a patch, we may have problems in terms of availability of data if the grid disk and the failure group is on the same cell.
My question though was can we create the grid disks such that their failure group would be on a separate cell and that an outage of a Storage cell (during patching ) would not result in a downtime for the database ?

Thanis
Vin

]]> By: Bill Doering http://blog.oracle-ninja.com/2011/12/exadata-diskgroup-planning/#comment-415 Bill Doering Fri, 13 Jan 2012 13:17:30 +0000 http://blog.oracle-ninja.com/?p=334#comment-415 Andy – For the majority of installations I would agree that RECO, DATA, and DBFS_DG would be acceptable and allow the greatest flexibility for future management. My question would be for a specific sector of businesses, the ones that don’t like to share SAN space, data, etc., in particular government bodies. In your opinion, how do you best handle issues where it isn’t so much technical as it is a political issue? It would be a problem seen in consolidation projects, for example three “organizations” within a government body want to share an Exadata system, but not data so storage can’t be co-mingled. Options could be ASM security, DB security, segregate storage servers associated to database machines, or just add specific disk groups for each database across all storage nodes (which is less “secure” but perhaps more manageable). I wonder which of those options still allows the greatest management ability, without compromising the security and political policies of such an organization.

– Bill

]]> By: Blog: Exadata Diskgroup Planning | Oracle | Syngu http://blog.oracle-ninja.com/2011/12/exadata-diskgroup-planning/#comment-358 Blog: Exadata Diskgroup Planning | Oracle | Syngu Sat, 24 Dec 2011 06:39:04 +0000 http://blog.oracle-ninja.com/?p=334#comment-358 [...] Andy Colvin launches a new series of posts covering Exadata configuration with a look at ASM diskgroup layout.    Oracle Read the original post on Oracle Technology Network… [...]

]]>