| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Solaris/Veritas filesystem for Oracle
Well, I don't know if this is the whole problem, but at least part of
the problem is this:
v odsd2 - ENABLED ACTIVE 174080000 SELECT
odsd2-02 fsgen
pl odsd2-01 odsd2 ENABLED ACTIVE 174082473 CONCAT -
RW
sd lst1dg01-02 odsd2-01 lst1dg01 6144903 31833891 0
c5t32d0 ENA
sd lst1dg03-01 odsd2-01 lst1dg03 0 71124291 31833891
c5t34d0 ENA
sd lst1dg04-01 odsd2-01 lst1dg04 0 71124291 102958182
c5t35d0 ENA
pl odsd2-02 odsd2 ENABLED ACTIVE 174085542 STRIPE 3/128
RW
sd lst1dg16-03 odsd2-02 lst1dg16 3007449 58028454 0/0
c5t54d0 ENA
sd lst1dg17-03 odsd2-02 lst1dg17 3007449 58028454 1/0
c5t55d0 ENA
sd lst1dg18-03 odsd2-02 lst1dg18 3007449 58028454 2/0
c5t56d0 ENA
This volume (and most of the volumes - this is just an example), odsd2 is actually two plexes. My veritas is a wee bit rusty, but as I read this, the two plexes odsd2-01 and odsd-02 are mirrored. However, the first plex odsd2-01, is a concatenated plex, while the second plex is a striped. The implication of that is that if you're only using 20% of the total amount of space for actual data, all writes are going only to the first drive in the concatenated plex - basically, for writes, you're getting none of the advantages of striping. For reads, you're just taking a performance hit, since veritas uses some load-balancing to determine which side of the mirror to read from.
Soooo, I'd rework the whole setup such that it uses 0+1 the whole way through, no mixing plex types, and take it from there. Again, storage vendor, database i/o patterns, etc. all vary, and thus your mileage will too. But that's the first thing that jumps out at me as a performance problem.
Thanks,
Matt
-- Matthew Zito GridApp Systems Email: mzito_at_gridapp.com Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.comReceived on Mon Jul 21 2003 - 14:20:01 CDT
> -----Original Message-----
> From: Roger Xu [mailto:roger_xu_at_dp7uptx.com]
> Sent: Monday, July 21, 2003 11:53 AM
> To: ORACLE-L_at_fatcity.com
> Cc: mzito_at_gridapp.com
> Subject: RE: Solaris/Veritas filesystem for Oracle
>
>
> the following 6 volumes have all my datafiles,
>
> [lostdog]root:/tmp>df -k | grep sapdata | sort
> /dev/vx/dsk/lst1dg/odsd1 15260136 14811592 295944 99%
> /oracle/DV2/sapdata1
> /dev/vx/dsk/lst1dg/odsd2 86474632 80075904 5533984 94%
> /oracle/DV2/sapdata2
> /dev/vx/dsk/lst1dg/odsd3 55954312 53925072 1469704 98%
> /oracle/DV2/sapdata3
> /dev/vx/dsk/lst1dg/odsd4 14242376 13831056 268904 99%
> /oracle/DV2/sapdata4
> /dev/vx/dsk/lst1dg/odsd5 15260136 14271616 835920 95%
> /oracle/DV2/sapdata5
> /dev/vx/dsk/lst1dg/odsd6 17294408 16187536 933928 95%
> /oracle/DV2/sapdata6
>
> Thanks,
>
> Roger
>
> -----Original Message-----
> From: Matthew Zito [mailto:mzito_at_gridapp.com]
> Sent: Monday, July 21, 2003 12:29 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Solaris/Veritas filesystem for Oracle
>
>
>
> Hrrrmm....hard to say from just that. Would you be
> comfortable sending a vxprint -g lst1dg -hrt so we can see
> how the volumes got created?
>
> Thanks,
> Matt
>
> --
> Matthew Zito
> GridApp Systems
> Email: mzito_at_gridapp.com
> Cell: 646-220-3551
> Phone: 212-358-8211 x 359
> http://www.gridapp.com
>
> > -----Original Message-----
> > From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On
> > Behalf Of Roger Xu
> > Sent: Monday, July 21, 2003 12:04 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Solaris/Veritas filesystem for Oracle
> >
> >
> > Hi,
> >
> > After I moved all my Oracle tablespace datafiles to ufs
> > filesystems in Veritas Volume, the database performance
> > suffers a whole lot.
> >
> > I think the problem is in the way I create the volume or the
> > way I create the filesystem.
> >
> > vxassist -g lst1dg make odata1 55000m layout=stripe nstripe=3
> > newfs -i 20000 -m 1 -b 8192 -f 8192 /dev/vx/rdsk/lst1dg/odata1
> >
> > Anybody has any insights?
> >
> > Thanks,
> >
> > Roger Xu
> > Database Administrator
> > Dr Pepper Bottling Company of Texas
> > (972)721-8337
> >
> >
> > ______________________________________________________________
> > __________
> > This email has been scanned for all viruses by the
> > MessageLabs Email Security System. For more information on a
> > proactive email security service working around the clock,
> > around the globe, visit http://www.messagelabs.com
> > ______________________________________________________________
> > __________
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Roger Xu
> > INET: roger_xu_at_dp7uptx.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web
> hosting services
> >
> ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> > and in the message BODY, include a line containing: UNSUB
> > ORACLE-L (or the name of mailing list you want to be removed
> > from). You may also send the HELP command for other
> > information (like subscribing).
> >
> >
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Matthew Zito
> INET: mzito_at_gridapp.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> and in the message BODY, include a line containing: UNSUB
> ORACLE-L (or the name of mailing list you want to be removed
> from). You may also send the HELP command for other
> information (like subscribing).
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the
> MessageLabs Email Security System. For more information on a
> proactive email security service working around the clock,
> around the globe, visit http://www.messagelabs.com
> ______________________________________________________________
> __________
>
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the
> MessageLabs Email Security System. For more information on a
> proactive email security service working around the clock,
 |
 |