SEO

Dear DBAs,

from what I have learned one should keep things seperate in an
produktive Oracle DB:

online redologs:
on 2 different dedicated physical disks (raid sets), groups swiching
from one disk to another

archive logs:
on another dedicated disk (raid set)

datafiles for undo/redo TSP on RAID 1
datafiles for temp TSP on RAID 1

other dataflies on RAID 5

controlfiles 3 all on different physical disks.


Now I'm confronted with a setup where all data is stored in a T1 storage
system which internally does a RAID 5. Everything in this storage is
software mirrored in another T1.

Both RAC nodes use this storage system for all oracle relevant files
redologs, archivelogs, controlfiles ...

Plus the shadow DB uses this storage system for all its files too.

Everything is connect through fiberchannel switches.

Is this insane? Or does it just look mad to me? Or is this the modern
way of doing things?

Can you please comment on this!

Greetings Roman

Roman Klesel wrote:

> Dear DBAs,
>
> from what I have learned one should keep things seperate in an
> produktive Oracle DB:
>
> online redologs:
> on 2 different dedicated physical disks (raid sets), groups swiching
> from one disk to another
>
> archive logs:
> on another dedicated disk (raid set)
>
> datafiles for undo/redo TSP on RAID 1
> datafiles for temp TSP on RAID 1
>
> other dataflies on RAID 5
>
> controlfiles 3 all on different physical disks.
>
>
> Now I'm confronted with a setup where all data is stored in a T1 storage
> system which internally does a RAID 5. Everything in this storage is
> software mirrored in another T1.
>
> Both RAC nodes use this storage system for all oracle relevant files
> redologs, archivelogs, controlfiles ...
>
> Plus the shadow DB uses this storage system for all its files too.
>
> Everything is connect through fiberchannel switches.
>
> Is this insane? Or does it just look mad to me? Or is this the modern
> way of doing things?
>
> Can you please comment on this!
>
> Greetings Roman

It works just fine. Let the SAN or NAS handle the problem. Once you've
written to the head ... the rest can just be ignored.

With RAW we got rid of file systems. With 10g even the volume management
can go away. It is a brave new world ... every 5 years or so.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

On Thu, 29 Jan 2004 08:29:27 -0800, Daniel Morgan
<damorgan@x.washington.edu> wrote:

>It works just fine. Let the SAN or NAS handle the problem. Once you've
>written to the head ... the rest can just be ignored.
>
>With RAW we got rid of file systems. With 10g even the volume management
>can go away. It is a brave new world ... every 5 years or so.

Do you mean this seriously, or are you just being cynical?
To me the proposed configuration looks like it has been designed by
someone who is either just released from a mental asylum or is a bean
counter (or both)


--
Sybrand Bakker, Senior Oracle DBA

Roman Klesel <rupa@firemail.de> wrote in message news:<bvb4c8$2ku$1@ork.noris.net>...
> Dear DBAs,
>
> from what I have learned one should keep things seperate in an
> produktive Oracle DB:
>
> online redologs:
> on 2 different dedicated physical disks (raid sets), groups swiching
> from one disk to another
>
> archive logs:
> on another dedicated disk (raid set)
>
> datafiles for undo/redo TSP on RAID 1
> datafiles for temp TSP on RAID 1

tempfiles

> other datafiles on RAID 5
>
> controlfiles 3 all on different physical disks.
>
> Now I'm confronted with a setup where all data is stored in a T1 storage
> system which internally does a RAID 5. Everything in this storage is
> software mirrored in another T1.

some might call this RAID 15

> Both RAC nodes use this storage system for all oracle relevant files
> redologs, archivelogs, controlfiles ...
>
> Plus the shadow DB uses this storage system for all its files too.
>
> Everything is connect through fiberchannel switches.

I hope its multipathed.

> Is this insane?

Check out James Morle's paper "Sane SAN"
up on OakTable http://www.oaktable.net or BAARF http://www.baarf.com

There are papers up there also that discuss RAID, but it seems that
the RAID config is already determined, out of your control, etc.

> Or does it just look mad to me? Or is this the modern
> way of doing things?
>
> Can you please comment on this!
>
> Greetings Roman

Roman,

Do you get to keep a backup set on something other than the T1 units?
(and I don't mean tape).
use at least 4 redo log groups, with at least 2 members per group.
size the logs so that the log switches co-incide with your recovery
objectives.
If you want a log switch every 60 minutes and all of your transactions
occur during an 8am to 6pm window, then you could roughly estimate
your log size from:

select to_char(completion_time,'Day HH24') day_hour, count(1),
trunc(sum(blocks*block_size)/1048576) mb,
round(trunc(sum(blocks*block_size)/1048576)/count(1),2) avg_log
from v$archived_log
where substr(to_char(completion_time,'Day'),1,1)!='S'
and to_char(completion_time,'HH24') between '08' and '18'
group by to_char(completion_time,'Day HH24')
/

and set the parameter archive_lag_target to the switch interval in
seconds (e.g. 3600).

If you size the online redo logs too small, you'll introduce more log
file switches, and therefore have more checkpoints occur, which
includes overhead.

hth.

Pd

Sybrand Bakker wrote:

> On Thu, 29 Jan 2004 08:29:27 -0800, Daniel Morgan
> <damorgan@x.washington.edu> wrote:
>
>
>>It works just fine. Let the SAN or NAS handle the problem. Once you've
>>written to the head ... the rest can just be ignored.
>>
>>With RAW we got rid of file systems. With 10g even the volume management
>>can go away. It is a brave new world ... every 5 years or so.
>
>
> Do you mean this seriously, or are you just being cynical?
> To me the proposed configuration looks like it has been designed by
> someone who is either just released from a mental asylum or is a bean
> counter (or both)
>
>
> --
> Sybrand Bakker, Senior Oracle DBA

Seriously.

With NetApp or EMC ... the one's I'm familiar with ... once you've
written to the head you can just ignore it ... questions about
stripping, mirroring, RAID, etc. are irrelevant. The head takes full
responsiblity for reading, writing, and recovery.

I've also come to the point where I think backing up to tape is a
ridiculous waste of time and money. These days you can back up to hard
disks far faster and for the same money. Fill a disk, pop it out,
replace it with another. Recycle hard disks not tape.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan wrote:
> Sybrand Bakker wrote:
>
>> On Thu, 29 Jan 2004 08:29:27 -0800, Daniel Morgan
>> <damorgan@x.washington.edu> wrote:
>>
>>
>>> It works just fine. Let the SAN or NAS handle the problem. Once
>>> you've written to the head ... the rest can just be ignored.
>>>
>>> With RAW we got rid of file systems. With 10g even the volume
>>> management can go away. It is a brave new world ... every 5 years or so.
>>
>>
>>
>> Do you mean this seriously, or are you just being cynical?
>> To me the proposed configuration looks like it has been designed by
>> someone who is either just released from a mental asylum or is a bean
>> counter (or both)
>>
>>
>> --
>> Sybrand Bakker, Senior Oracle DBA
>
>
> Seriously.
>
> With NetApp or EMC ... the one's I'm familiar with ... once you've
> written to the head you can just ignore it ... questions about
> stripping, mirroring, RAID, etc. are irrelevant. The head takes full
> responsiblity for reading, writing, and recovery.
>
> I've also come to the point where I think backing up to tape is a
> ridiculous waste of time and money. These days you can back up to hard
> disks far faster and for the same money. Fill a disk, pop it out,
> replace it with another. Recycle hard disks not tape.
>

Hmmm...!

So there seems to be a quite spread out spectrum of opinions about this.

My main 2 doubts in this whole setup are:

1) The storage System (althogh it has redundant components) remmains a
single point of failure for all 3 instances: RAC1, RAC2 and shadow.

2) Does such a storage system prevent I/O contentions effectively
between REDLOG ARCHIVELOG and DATA/TEMP File aktivity?

BTW. We also use RAW devices ... what a hassle ...

Regars Roman

> Roman,
>
> Do you get to keep a backup set on something other than the T1 units?
> (and I don't mean tape).

I don't really understand what you mean here.
We do an RMAN Backup to a NFS mounted Filesytem (another point that I'm
very suspicious about.

Otherwise no. Everything live and shadow DB resides on different
partitions/RAW devices on the 2 T1s which are software mirrored.

> use at least 4 redo log groups, with at least 2 members per group.
> size the logs so that the log switches co-incide with your recovery
> objectives.

That's the case here.

> If you want a log switch every 60 minutes and all of your transactions
> occur during an 8am to 6pm window, then you could roughly estimate
> your log size from:
>
> select to_char(completion_time,'Day HH24') day_hour, count(1),
> trunc(sum(blocks*block_size)/1048576) mb,
> round(trunc(sum(blocks*block_size)/1048576)/count(1),2) avg_log
> from v$archived_log
> where substr(to_char(completion_time,'Day'),1,1)!='S'
> and to_char(completion_time,'HH24') between '08' and '18'
> group by to_char(completion_time,'Day HH24')
> /

Thanks I will use this for optimisation. Until now I was examining the
ceckpionts written to the alertfile in order to calculate the frequency
of the log switches.

>
> and set the parameter archive_lag_target to the switch interval in
> seconds (e.g. 3600).

Thanks I was allready looking for the cause of the log switches every 30
min.


I'm quite surprised that the idea to just dump everything into a black
box is that much accepted. I'm coming from the SAP scene and the
performace people there still totally doom this concept. Especially
putting Redolog files on such a box. They just hate RAID5.

Roman

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1075443006.598594@yasure>...

> With NetApp or EMC ... the one's I'm familiar with ... once you've
> written to the head you can just ignore it ... questions about
> stripping, mirroring, RAID, etc. are irrelevant. The head takes full
> responsiblity for reading, writing, and recovery.

I think this is true only if we're talking about cheap low end arrays.
We have here EMC's Symmetrixes and it seems to me like there is quite
a lot of things that you can setup (or in my case messed up). You can
specify for example RAID levels, which disks will be part of which
"volume group", many communication parameters etc.

> I've also come to the point where I think backing up to tape is a
> ridiculous waste of time and money. These days you can back up to hard
> disks far faster and for the same money. Fill a disk, pop it out,
> replace it with another. Recycle hard disks not tape.

However, tape could be quicker ... strange but true.

--
Dusan Bolek

On Thu, 29 Jan 2004 22:11:08 -0800, Daniel Morgan
<damorgan@x.washington.edu> wrote:

<snip>
>
>I've also come to the point where I think backing up to tape is a
>ridiculous waste of time and money. These days you can back up to hard
>disks far faster and for the same money. Fill a disk, pop it out,
>replace it with another. Recycle hard disks not tape.

Or one could use a tape managment system that virtualizes the whole
operation, and actually uses disk as an asynch buffer between the tape
and the 'application.' We use Tivioli Storage Manager in this
fashion. From my view, I'm writing backups to neither 'tape' nor
'disk' but simply to the TSM system. But within that system, my write
ends up going directly to a disk, from where it is later copied to
tape. So I get the storage advantages of tape without having to wait
on tape mounts and availability.

On Fri, 30 Jan 2004 08:10:28 +0100, Roman Klesel <rupa@firemail.de>
wrote:

>
>> Roman,
>>
>> Do you get to keep a backup set on something other than the T1 units?
>> (and I don't mean tape).
>
>I don't really understand what you mean here.
>We do an RMAN Backup to a NFS mounted Filesytem (another point that I'm
>very suspicious about.
>
>Otherwise no. Everything live and shadow DB resides on different
>partitions/RAW devices on the 2 T1s which are software mirrored.
>
>> use at least 4 redo log groups, with at least 2 members per group.
>> size the logs so that the log switches co-incide with your recovery
>> objectives.
>
>That's the case here.
>
>> If you want a log switch every 60 minutes and all of your transactions
>> occur during an 8am to 6pm window, then you could roughly estimate
>> your log size from:
>>
>> select to_char(completion_time,'Day HH24') day_hour, count(1),
>> trunc(sum(blocks*block_size)/1048576) mb,
>> round(trunc(sum(blocks*block_size)/1048576)/count(1),2) avg_log
>> from v$archived_log
>> where substr(to_char(completion_time,'Day'),1,1)!='S'
>> and to_char(completion_time,'HH24') between '08' and '18'
>> group by to_char(completion_time,'Day HH24')
>> /
>
>Thanks I will use this for optimisation. Until now I was examining the
>ceckpionts written to the alertfile in order to calculate the frequency
>of the log switches.
>
>>
>> and set the parameter archive_lag_target to the switch interval in
>> seconds (e.g. 3600).
>
>Thanks I was allready looking for the cause of the log switches every 30
>min.
>
>
>I'm quite surprised that the idea to just dump everything into a black
>box is that much accepted. I'm coming from the SAP scene and the
>performace people there still totally doom this concept. Especially
>putting Redolog files on such a box. They just hate RAID5.
>
>Roman

Sounds like they can't make the mental leap from dealing with
discrete, dedicated disks to SAN units with massive amounts of
parallelism. And while I've never worked with SAP, it doesn't take
much reading in this very ng to see a general consensus that the app
itself is a performance dog in its own right. If that is true, and
based on my own experience with other app vendors, they'll look for
any excuse, no matter how slim or unsubstantiated, to place
performance blame somewhere outside of their app.