Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> problem: e4500, controllers, disk arrays (5200) and Volume Manager

problem: e4500, controllers, disk arrays (5200) and Volume Manager

From: Andrei <andreyNSPAM_at_bookexchange.net>
Date: Wed, 25 Apr 2001 21:37:23 GMT
Message-ID: <3ae7443d.1228102377@news.earthlink.net> 






Hi,



I am not an experienced Unix Admin, nor am I one at all (so, please,
take it easy on me :). But since our Unix Admin recently quit, I am
looking into some problems which I think exist in the config of the
servers.



We recently migrated from one hosting facility to another. And we now
have an identical server at a new facility.. but something looked
fishy to me..



So it looks like that our Unix admin configured the disk array so that
it only uses one disk controller.



vxprint -d


Disk group: rootdg



TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE

TUTIL0  PUTIL0



dm rootdisk     c0t10d0s2    -        35835786 -        -        -


-



dm rootmir      c0t11d0s2    -        35835786 -        -        -


-




Disk group: dragondg



TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE

TUTIL0  PUTIL0



dm frontd0      c1t0d0s2     -        17678493 -        -        -


-



dm frontd1      c1t1d0s2     -        17678493 -        -        -


-



dm frontd2      c1t2d0s2     -        17678493 -        -        -


-



dm frontd3      c1t3d0s2     -        17678493 -        -        -


-



dm frontd4      c1t4d0s2     -        17678493 -        -        -


-



dm frontd5      c1t5d0s2     -        17678493 -        -        -


-



dm frontd6      c1t6d0s2     -        17678493 -        -        -


-



dm frontd7      c1t7d0s2     -        17678493 -        -        -


-



dm frontd8      c1t8d0s2     -        17678493 -        -        -


-



dm frontd9      c1t9d0s2     -        17678493 -        -        -


-



dm frontd32     c1t32d0s2    -        17678493 -        -        -


-



dm frontd33     c1t33d0s2    -        17678493 -        -        -


-



dm frontd34     c1t34d0s2    -        17678493 -        -        -


-



dm frontd35     c1t35d0s2    -        17678493 -        -        -


-



dm frontd36     c1t36d0s2    -        17678493 -        -        -


-



dm frontd37     c1t37d0s2    -        17678493 -        -        -


-



dm frontd38     c1t38d0s2    -        17678493 -        -        -


-



dm frontd39     c1t39d0s2    -        17678493 -        -        -


-



dm frontd40     c1t40d0s2    -        17678493 -        -        -


-



dm frontd41     c1t41d0s2    -        17678493 -        -        -


-



dm spare10      c1t10d0s2    -        17678493 -        SPARE    -


-



dm spare42      c1t42d0s2    -        17678493 -        SPARE    -




while the old server seemed to have used two (for the disk array)
$vxprint -d


Disk group: rootdg



TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE

TUTIL0  PUTIL0



dm rootdisk     c0t10d0s2    -        17678493 -        -        -


-



dm rootmir      c0t11d0s2    -        17678493 -        -        -


-




Disk group: smaugdg



TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE

TUTIL0  PUTIL0



dm frontd96     c1t96d0s2    -        17678493 -        -        -


-



dm frontd97     c1t97d0s2    -        17678493 -        -        -


-



dm frontd98     c1t98d0s2    -        17678493 -        -        -


-



dm frontd99     c1t99d0s2    -        17678493 -        -        -


-



dm frontd100    c1t100d0s2   -        17678493 -        -        -


-



dm frontd101    c1t101d0s2   -        17678493 -        -        -


-



dm frontd102    c1t102d0s2   -        17678493 -        -        -


-



dm frontd103    c1t103d0s2   -        17678493 -        -        -


-



dm frontd104    c1t104d0s2   -        17678493 -        -        -


-



dm frontd105    c1t105d0s2   -        17678493 -        -        -


-



dm frontd106    c1t106d0s2   -        17678493 -        SPARE    -


-



dm reard112     c2t112d0s2   -        17678493 -        -        -


-



dm reard113     c2t113d0s2   -        17678493 -        -        -


-



dm reard114     c2t114d0s2   -        17678493 -        -        -


-



dm reard115     c2t115d0s2   -        17678493 -        -        -


-



dm reard116     c2t116d0s2   -        17678493 -        -        -


-



dm reard117     c2t117d0s2   -        17678493 -        -        -


-



dm reard118     c2t118d0s2   -        17678493 -        -        -


-



dm reard119     c2t119d0s2   -        17678493 -        -        -


-



dm reard120     c2t120d0s2   -        17678493 -        -        -


-



dm reard121     c2t121d0s2   -        17678493 -        -        -


-



dm reard122     c2t122d0s2   -        17678493 -        SPARE    -


- -




Which I believe now significantly slows down (oracle) batch jobs
running at nights, since mirrors used to use the second controller.



So questions I have are are:



    
  
  1.   are the disk controllers physically in the server, or disk array?
  i got some feedback that the controllers are in the 4500
  
  2.   can I easily make those disks use the second controller, or will
some rewiring need to take place? (and if i do, will i have to do this
on VM level or solaris level)
  
  3.   if some rewiring will need to take place, would I be able to
disable the mirrors, rewire the disk arrays, and then rebuild/possibly
import the old volumes and resync mirrors (i am not at the same
physical locations as the disks are, so i'll have to coordinate it
with hosting facility ppl)
  
  4.   do i know what I am talking about at all :)?







Thanx for any kind help.






In case I forgot to mention: 


We use Oracle 7.3.4 and 8.1.6 on Solaris 2.6, 2.7 boxes



Andrey Dmitriev	 eFax: (978) 383-5892  Daytime: (917) 750-3630
AOL: NetComrade	 ICQ: 11340726 remove NSPAM to email


Received on Wed Apr 25 2001 - 16:37:23 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US