How to do disk slicing on Sun stroEdge A3500 Boxes

Hi everyone, H/W : Sun E10000 Ifmx : XPS 821.UD4 [ 6 coserver environment] O/S : Solaris 2.5.1 Machine configuration : Sun E10000 with 7 Sun StorEdge A3500. All 7 A3500 has 14 internal controller, 2 internal controller per A3500. Every A3500 has 5 disk tray of 7 physical disk of 9 GB each. So every A3500 has 7*5 i.e. 7 luns of 5 disk each. Every lun has 5 (9 GB each) disk. Every lun has 17 (2 GB slices), rest of the space is for file systems. Since every A3500 has 2 internal controller, so every lun is on different controller like if controller are c1, c3 then lun allocation will be l1 will be on c1, l2 will be on c2, l3 will be on c1 and so on ....l7 will be on c1. Problem : I have 6 coserver environment. I need to load a fact table of 14 month of data. so far I am able to calculate that every month will be having 18 (2 GB slices i.e. 3 layers of 2 Gb slices all over the 6 coserver). The problem is HOW TO ALLOCATE ALL 2 GB SLICES OVER DIFFERENT CONTROLLER, DIFFERENT LUNS AND OVER DIFFERENT BOXES. I have 4 main fact table. I am looking for some logic where i can come out with the kind of name like b-box, l-lun, s-slice if i see b01l00s01-> this kind of nomenclature can tell me that which controller my slice is b'coz every lun will be on different controller. I am sorry if any one find it confusing but the fact is this is confusing. What i am trying to achieve is to use all the controller on all luns on all boxes, in order to avoid any I/O contentions for all fact tables. My fact tables will be fragmented on the basis of month. Also, i read many times that RAID5 strip block size should be 8*page size i.e. for xps it will be 32K. CAN SOME ONE TELL ME WHERE ICAN FIND SOMTHING LIKE THIS MENTIONED IN INFORMIX TECH OR SOME DOCUMENTATION where i can show to my mangers that this is documented OR ANY BENCHMARK SETUP. My team lead are not beleiving this. They think 8 K is the perfect size. I guess some 'O' dba might have told them Oracle work better with 8K, so they think the perfect strip size for all the DBMS is 8K. I guess that i tried to explain my problem the best i can. Excuse me if it is not explained in simple way. Thanks __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com

Sanjeev, I'm confused but that's not hard to do. :-) Please tell me, how many physical computers are in the cluster: Do you have 6 Sun E10000 computers or one computer??? It would be a major expenditure if you have six of these machines, but hey, somebody is really spending some serious money here. In my limited experience I would be more concerned about the layout of the data to avoid data skew. You have a good number of coservers to help accomplish this the key is setting up a spreadsheet of your disks with each month rotating across your coservers. Odd-numbers of coservers give you the greater possibility of data skew especially with month-based fact tables, because as you lay out the months across the coservers you will end up with odd-ball layouts. For example, your 6-coserver setup should give you two months per coserver. If you had an odd number of coservers, the distribution gets lopsided. If you load balance your data correctly according to XPS design the only other thing left to do is test it and see how it performs. And at this point I'd definitely get Informix ATG in on the testing and let them give you the inside track on what to do. They hear the latest on what people are doing and pass it on. Hope this helps, Tim sanjeev sagar wrote: > > Hi everyone, > > H/W : Sun E10000 > Ifmx : XPS 821.UD4 [ 6 coserver environment] > O/S : Solaris 2.5.1 > > Machine configuration : > > Sun E10000 with 7 Sun StorEdge A3500. All 7 A3500 has 14 internal > controller, 2 internal controller per A3500. Every A3500 has 5 disk > tray of 7 physical disk of 9 GB each. So every A3500 has 7*5 i.e. 7 > luns of 5 disk each. Every lun has 5 (9 GB each) disk. Every lun has 17 > (2 GB slices), rest of the space is for file systems. > > Since every A3500 has 2 internal controller, so every lun is on > different controller like if controller are c1, c3 then lun allocation > will be > > l1 will be on c1, l2 will be on c2, l3 will be on c1 and so on ....l7 > will be on c1. > > Problem : > > I have 6 coserver environment. I need to load a fact table of 14 month > of data. so far I am able to calculate that every month will be having > 18 (2 GB slices i.e. 3 layers of 2 Gb slices all over the 6 coserver). > The problem is > > HOW TO ALLOCATE ALL 2 GB SLICES OVER DIFFERENT CONTROLLER, DIFFERENT > LUNS AND OVER DIFFERENT BOXES. > > I have 4 main fact table. I am looking for some logic where i can come > out with the kind of name like > > b-box, l-lun, s-slice > > if i see b01l00s01-> this kind of nomenclature can tell me that which > controller my slice is b'coz every lun will be on different controller. > > I am sorry if any one find it confusing but the fact is this is > confusing. What i am trying to achieve is to use all the controller on > all luns on all boxes, in order to avoid any I/O contentions for all > fact tables. My fact tables will be fragmented on the basis of month. > > Also, i read many times that RAID5 strip block size should be 8*page > size i.e. for xps it will be 32K. > > CAN SOME ONE TELL ME WHERE ICAN FIND SOMTHING LIKE THIS MENTIONED IN > INFORMIX TECH OR SOME DOCUMENTATION where i can show to my mangers that > this is documented OR ANY BENCHMARK SETUP. My team lead are not > beleiving this. They think 8 K is the perfect size. I guess some 'O' > dba might have told them Oracle work better with 8K, so they think the > perfect strip size for all the DBMS is 8K. > > I guess that i tried to explain my problem the best i can. Excuse me if > it is not explained in simple way. > > Thanks > > > __________________________________________________ > Do You Yahoo!? > Bid and sell for free at http://auctions.yahoo.com -- . .- .-- .--- .---- Tim Schaefer .----- tschaefe@bellsouth.net .---- http://www.inxutil.com .--- http://www.datad.com .-- .- .