RE: Managing CPU_COUNT for micro-partitioning on AIX
- From: "Jesse, Rich" <Rich.Jesse@xxxxxx>
- To: <pythianbrinsmead@xxxxxxxxx>
- Date: Fri, 7 Jul 2006 12:30:46 -0500
Wow. Which DASDs did they expect you were using? ;)
And, yes, based on the excellent responses I've had in this thread, I
plan to override the _CPU_COUNT. Without checking, I would think that
the parameters derived from _CPU_COUNT would be static anyway, but I
don't need them changing on me if I should need to bounce the
instance(s).
I don't know if I'll get a chance to read much of the AIX manuals (save
for looking up "mpstat"!), but I trust the guys that are calling the
shots on the OS.
Thanks all for your help!
Rich
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mark Brinsmead
Sent: Thursday, July 06, 2006 9:52 PM
To: Brandon.Allen@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Managing CPU_COUNT for micro-partitioning on AIX
Cool. I now know a lot more than I did before. Thanks...
Still, in this situation, it would probably be wise to override the CPU
count the OS is reporting to the database. The OS is obviously lying.
;-)
Reading the AIX manuals more than the sysadmins do? That sounds all too
familiar.
As for not getting "root" passwords, well, that is not uncommon in my
experience. As a DBA, I have been given "root" passwords very rarely
indeed,
and as a sysadmin, I have provided "root" passwords to others even more
rarely. There are matters of responsibility and accountability that
need to
be respected, after all. But a sysadmin who disregards (database)
tuning advice from the DBAs (or vice versa) is usually ill advised.
Usually. ;-)
I do, however, remember times as a sysadmin when I had DBAs adamantly
insist that I must places specific data files on specific "cylinders"
and
specific "surfaces" of the 500 or so SCSI disks I was managing. After
explaining to deaf eafs that neither UNIX nor SCSI really work that way
"ignoring" was the only option I had left. Sometimes it *is* a good
strategy. ;-)
Other related posts:
