SuperDome and VPARS
- From: "Kline.Michael" <Michael.Kline@xxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 11 Jan 2005 09:14:44 -0500
We've got two data warehouses that we are going to migrate. Here were
some of the thoughts. I was wondering if anyone had the luxury of
testing BOTH ways and what they found out. NORMALLY the PRD database
builds a bunch of data which this then transferred to RPT for reporting,
so one is active and then the other, but both COULD be active at the
same time. These are almost 2TB each, so not that big. The application
NORMALLY shows signs of being I/O bound more than anything else due to
the size of the data.
Anyone "Been there, done that???"
I'm sort of inclined to keep the current way, one VPAR.
"I am sorry I have not been paying a much attention to the configuration
as I should, but I want to make a suggestion. The Superdome resources
for XXXXX appear to be 8 CPUs, 16 GB memory and 8 SAN cards. As I
understand, the current plan is to create two VPARS that have two
permanently assigned CPU's and the ability to acquire up to 4 'floating'
CPUs. Each would have a static amount of memory and each would have 4
SAN cards. I would suggest we put all of these resources into one vpar.
That way the two instances, pfrpt, pfprd would have full access to ALL
resources. This could improve I/O throughput, as well as provide more
combined memory and CPU power that two separate partitions. I don't
know about the other software systems (People tools, informatica), but
this seems like a superior configuration than two vpars who will have
unused computer resources at different times. What do you think?"
Michael Kline
Database Administration
SunTrust Technology Center
1030 Wilmer Avenue
Richmond, Virginia 23227
Outside 804.261.9446
STNet 643.9446
Cell 804.744.1545
<mailto:michael.kline@xxxxxxxxxxxx> michael.kline@xxxxxxxxxxxx
************************************************
The information transmitted is intended solely
for the individual or entity to which it is
addressed and may contain confidential and/or
privileged material. Any review, retransmission,
dissemination or other use of or taking action
in reliance upon this information by persons or
entities other than the intended recipient is
prohibited. If you have received this email in
error please contact the sender and delete the
material from any computer.
************************************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
