This content has been marked as final. Show 9 replies
With things like this there's no universal best solution.
I intend to stay away of discussing physical configuration meaning "what if redo logs are placed on SSD datagroup" is outside of the scope.
I usually create two diskgroups per database: DATA and FRA. As far as redo logs they're spread across the two by default if you use dbca to create the database (if I'm not mistaken).
Here is some practical advantages of using such configuration vs one diskgroup:
- FRA is usually smaller and its contents is changing much more often. It means it rebalances more often. There was a nasty bug in 10g where external redundancy diskgroup created with disks of different sizes would not automatically rebalance and run out of space with lots of actual space left. It had to be manually rebalanced every few days. If it was combined with the DATA diskgroup the process would take much longer.
- You can specify different AU sizes for different diskgroups. Let's say default for FRA and increased for DATA in case of Data Warehouse.
- I often refresh test environment from production backup. It's much faster to drop/create DATA diskgroup than delete a few Tb of datafiles in preparation. The backup is only good if you can restore from it, right? A separate FRA allows to keep ASM spfile intact during this process.
- In one of the databases FRA diskgroup is used for incrementally updated backup. If DATA diskgroup fails the database can be switched to the copy in no time. Of cause there's a tape backup on top of it.
I bet there would be people who would provide advantages of using several DATA diskgroups in addition to separate FRA. I just don't fancy micromanagement outside of the database. It does not mean these people would not have their point though.
Hope it helps.
Merlin128 wrote:Is this stand-alone ASM? or RAC? If it is RAC, Then you must use something for SHARED STORAGE - like SAN. I am not a fan of RAC on Windows but that is your call. ASM works best when 1) you use the entire device, 2) you have MULTIPLE devices , 3) you adequately protect your data. With either of your proposals, you are playing Russian Roulette with a loaded and chambered 9mm. The outcome will not be pretty.
I've been told to remove the database ASM drives from our company SAN..
SAN has 3 ASM partitions:
TS (tablespaces) 420GB Used
FRA (Flashback Recovery / RMAN) 515GB Used
REDO (Redo Logs) 10GB Used
currently 945GB Total Used (system has been active 1 year)
anticipated growth over the next 7 years will total 5TB in ASM
I have purchased new servers to load the database on
These are Windows 2008 R2 with 8TB available storage after raid 5 array
I am considering
Windows C: drive with oracle install and expdp_export folder to be 3TB
ASM partition for Tablespaces (TS) to be 2.5TB
ASM partition for flash/RMAN/REDO (FRA) to be 2.5TB
my question is.. should I leave the two ASM partitions seperate..
or could I just use 1 ASM partion for everything: Tablespaces, Flash, RMAN, REDO
Having a single disk (or in your case partition) is pretty worthless when using ASM as ASM works best when it is able to parallelize the I/O load.
So, if you are going to have 8TB after R5, then I am guessing you will have 5x2TB devices? Let ASM handle your data protection and not the RAID controller using NORMAL (2 copies) or HIGH (3 copies) of your data. I would do 3 Normal Redundancy for DATA + 2 Normal redundancy for FRA. This is not partition/device mirroring, it is 2 copies of the data place where it thinks it should go.
With all due respect to the previous reply author, letting DBCA do all of the work can lead to significant performance issues. You should understand everything about your configuration - down to the disk/controllers as well as understand the performance characteristics of the chosen configuration.
Edited by: onedbguru on Nov 26, 2012 3:44 PM
There is nothing wrong with using hardware RAID and external redundancy as mentioned in Oracle [url http://docs.oracle.com/cd/E11882_01/server.112/e18951/asmprepare.htm#BABJHHEC]documentation. It's not mandatory to create RAID 5 either.
DBCA is simply mentioned with regard to how it handles redo log allocation. There is no mystery in how it works though. All the scripts and logs are readily available for your review. There's always an option to run the scripts manually if you'd prefer. Not sure how it may affect performance though.
I thought so. Just for the sake of clarity could you, please, tell us what you mean by saying ASM partition? I would rather doubt you meant that ASM partition equals physical disk, but I could be wrong.
PS Since DBA job is all about details I would be hard-pressed to believe in Russian Roulette revolver chambered in 9mm. 7.62 as in Nagant or .38 Special as in Colt used by Red Shroud in The Deer Hunter sounds more believable. Great movie.
If you note, I did not say revolver. :) As a 9mm typically a semi-automatic.
I agree that external redundancy is acceptable. With the configuration detailed he would need to:
create one big [RAID5] device.
create multiple equal sized partitions.
create diskgroup using multiple partitions for DATA
create diskgroup using multiple partitions for FRA
That being said, I would still use the previously mentioned configuration letting ASM handle the redundancy.
So, we have detailed two valid configurations. Only extensive testing of each would give the OP the best for his situation. Or he can "punt" by picking one and hoping for the best.