Re: Oracle Enterprise Manager and the 4K block size
- From: Gus Spier <gus.spier@xxxxxxxxx>
- To: "Mark W. Farnham" <mwf@xxxxxxxx>
- Date: Mon, 2 Aug 2010 13:01:25 -0400
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
>
Other related posts:
