Re: Diagnostic & tuning pack

Be very careful in setting up OEM and using it (that is probably like saying 'don't cut yourself with that scalpel, it's sharp'.

A couple hints:

1. You're better off setting up an Oracle Enterprise Edition NT version database on the box you are going to use to house the OMS service thingie and have that machine be the data / study gatherer box and create the OEM repository in the local database in which to store the gathered data and analyses and such. Use that box to run your data gathering processes and to do the post-processing analysis and recommendations. Needless to say, that machine should not be ever shut down, if you plan to use OEM's job scheduling and management services and should be considered the OEM "server" if you will. And obviously, SQL*NET listener and SNMP management services should be up all the time on all Oracle servers, even if all the instances on a particular server might be down for cold backups, or whatever. (And you ought to always start your listener services before your instances, and only shut them down (if need be), after the instances on that machine have been shut down.)
2. You should ensure that the OEM server has a unique and dedicated SQL*NET service address, for its sole use, on all managed machines; I often use 1528 and 1529 (you need a port each for inbound and outbound agent requests) (the SNMP guy) and an additional service address, like 1527, for the dedicated link to the database. Or just pick any ports you fancy, as long as you have three for each managed machine, reserved for OEM use only, but if possible, I like to block out #1521 to #1529, or preferably #1521 to #1539, for Oracle use only. (Make sure that block of addresses is documented in the /etc/services file, even if you aren't using them yet!.)

(Net8's big deal assistant (ONM's replacement) (not the simple "easy setup" one) makes this a bit less painful, and builds a handy network map in the process as well.).

 Ensure TNSNAMES on the OEM server includes SERVER=DEDICATED. Use raw tcp/ip addresses, rather than machine (node) names, for the Oracle DBMS servers you are monitoring and managing (Don't depend on DNS or Oracle Names; yes it is yuccky to hardcode this, but it is only on the OMS server this need be done.)

Why? If your DNS servers go down, or Oracle Names goes down (or the machines that either or both run on), you are dead in the water, otherwise. Just bear in mind that the OMS server's SQL*NET files must be kept up to date.

3) Run your data gathering sessions for as long a period of time as possible, preferably a segment of time that reflects a chunk of time that encompasses your peak interactive processing load, as well as a segment of time that covers night batch or other processing you might do.

4) Describe your environment as much as you can to OEM; tell it how much memory each machine has, how many processors, as much as you possibly can that it wants to know; it can't get a lot of these data, and it ought all to be entered before embarking on a data gathering/analysis/recommendation run. Tell it how much memory is reserved for Oracle, whether it's an OLTP or DSS or mixed environment, acceptable downtime, everything you can.

The analyses and recommendations are affected by these data.

5) You'll get SQL scripts and other things at the other end of this process. Examine every line closely to make sure every recommended change makes sense. Never just run the stuff that comes out of Recommendation/Implementation without looking at it and commenting out things you don't want. {And ensure control files, inits, yadda yadda yadda, are all safely copied, and it would not hurt also to build scripts using "SQL that writes SQL" to build a script to recreate all your indices, and keep that safe, too.)

6) The more data you collect and add to the OEM repository about an instance, the more finely tuned OEM analysis becomes. OEM may tell you to drop x,y, and z indices based on non-usage and the overhead they cause; if you don't let OEM gather data over representative periods of time, it may not know those indices are used for some infrequently run process.

7) Make sure you have fresh, complete statistics in the instance; don't use the OEM option to let it make its own. DBMS_UTILITY has (or used to have) an ANALYZE_SCHEMA deal that made it pretty easy. (Don't be greedy, depending on how large your schemata are, you mightn't wish to run this; and in any case, TEMP will take a beating as well as CPU time, so this should be done on off-hours preceding your analysis.) And I highly don't recommend ANALYZEing more than one schema at a time. You should have fresh, accurate stats to support the CBO anyhow, so this might be needless advice.

Anyhow, the packs are very helpful, just be judicious in their use.

RSH. "MauMau" <gitaya_at_hotmail.com> wrote in message news:1391a36e.0204210303.2e2d94cf_at_posting.google.com...
> Hi,
> How do I get these packs for 8i?
> Tia
> MauMau
Received on Sun Apr 21 2002 - 14:08:30 CDT