Re: Oracle Enterprise Manager and the 4K block size
- From: Ram Srinivasan <srinivasanram2004@xxxxxxxxx>
- To: gus.spier@xxxxxxxxx
- Date: Sun, 8 Aug 2010 09:29:05 -0400
Gus!
We have OEM repository on a different server than the database server.
Once you get to know OEM, it is fantastic. It is all click and enter.
That is all. Never put the OEM repository on the database server. OEM ,
if possible, must have its own server. If you put the OEM along with the
database, you will have lots of performance problems.
Ram Srinivasan
On Mon, Aug 2, 2010 at 1:01 PM, Gus Spier <gus.spier@xxxxxxxxx> wrote:
> Mark, clearly, that is the solution. I hadn't really considered it because
> of perceived potential hassles with configuration management.
>
> But anything has to be easier than what I am leaping though now ..
>
> Thanks,
>
> Gus
> On Mon, Aug 2, 2010 at 10:05 AM, Mark W. Farnham <mwf@xxxxxxxx> wrote:
>
>> Why would you like to put the OEM repository in the existing production
>> database?
>>
>>
>>
>> Would it not be simpler to create a new database just for OEM? That, of
>> course, opens up the complete vista of possibilites of maintaining OEM’s
>> database server complex (which should be relatively modest in size compared
>> to “real” stuff) to emphasize availability and to be de-coupled from
>> maintenance cycles on your production database.
>>
>>
>>
>> Of course one of the times you’ll want to use OEM most without worries of
>> its overhead is when there is a performance challenge on one of the
>> production databases. No matter how efficient OEM is made in RDBMS service
>> requirements, some is more than none. If the limit is network access, that
>> is all I can think of that OEM’s repository being elsewhere imposes as a
>> resource consumer. There may be licensing issues, but that might actually
>> come out in favor of OEM’s repostitory be elsewhere if you choose to gen it
>> up on multiple small nodes active-passive for hardware preventive
>> maintenance without OEM repository downtime. Your mileage will vary.
>>
>>
>>
>> Even if you choose to not put the OEM repository on a different platform,
>> you should be able to minimize the overhead of a smallish SGA for a separate
>> instance on the incumbent platform, and, again, minimize the linkage between
>> maintenance cycles of the OEM repository and the production databases. Then
>> at least the OEM repository’s loads on things like latching, cache, shared
>> sql, log file sync, etc. are largely decoupled from any issues on the
>> databases it is being used to monitor.
>>
>>
>>
>> Again, to be clear, I am NOT indicting the OEM repository’s load. But if
>> OEM needs to execute transactions it may to some extent be impeded by
>> performance issues on the database it is being used to monitor if it is
>> co-located.
>>
>>
>>
>> Presumably the “hard-coded” references to the dbname do not include the
>> yet to be implemented OEM. If they do, they should be in the gambling
>> business.
>>
>>
>>
>> Good luck,
>>
>>
>>
>> mwf
>> ------------------------------
>>
>> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
>> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Gus Spier
>> *Sent:* Friday, July 30, 2010 2:22 PM
>> *To:* oracle-l
>> *Subject:* Oracle Enterprise Manager and the 4K block size
>>
>>
>>
>> oracle rdbms 10.2.0.2
>>
>> solaris 10
>>
>>
>>
>> "Expediency is the enemy of integrity". And the consequences of choosing
>> expediency apparently last forever.
>>
>>
>>
>> So, in Bad Old Days, the previous incumbent selected a value for
>> db_block_size
>> of 4096. No doubt, that was the only value available to them at the time,
>> what and all with the pre-historic transition from Big Iron to
>> microcomputers.
>>
>>
>>
>> No one has seen a need to modify the db_block_size since those stirring
>> times.
>>
>>
>>
>> Now comes the New Guys ... who think they are going to do it better,
>> cheaper, faster, blah blah blah. "We'll take advantage of modern tools,
>> like Oracle Enterprise Manager and Grid Control. We'll let the service
>> center monitor the databases and free up numerours hours for REAL DBA work."
>>
>>
>>
>> Have you ever tried to implement OEM on a database with a db_block_size of
>> 4096? When you have finally finished beating your head against the wall,
>> you read the message, " db_block_size must be at least 8192 "
>>
>>
>>
>> OK, not a problem. We know we cannot simply issue an "ALTER SYSTEM ..."
>> command and expect it to work. We'll practice with Data Pump and export the
>> entire database; change the database parameter to 4096; and perform the
>> import.
>>
>>
>>
>> Well, maybe not ...
>>
>>
>>
>> Now our latest theory is:
>>
>> 1. New initSID.ora with the target db_block_size set to 8192
>> 2. Export the source db
>> 3. start up the *new db* with new initSID.ora
>> 4. Import the source database from the .dmp files
>>
>> Then someone objects, "Wait a minute, did he say 'New DB?!' No way.
>> We'd have to change hard-coded references that have been growing like Topsy
>> since 1995! We'll have days and weeks of downtime!"
>>
>>
>>
>> So, before I shrug off this latest disappointment and go back to wading
>> through four levels on indirection worth of shell scripts ... I remember
>> that OEM was owner by SYSMAN ... and I think I remember that SYSMAN had a
>> default tablespace of SYSAUX ... Does that mean I might be able to make a
>> SYSAUX tablespace with a default block size of 8k and fool the OU Installer
>> into letting me make progress?
>>
>>
>>
>> Does anybody know?
>>
>>
>>
>> r,
>>
>>
>>
>> Gus
>>
>
>
--
Sincerely
Ram Srinivasan
Other related posts:
