Re: OEM Tuning/Diagnostics Pks on Sun Solaris ?

Raghu's nailed that one.

Oracle could be a bit more clear that OEM & packs RUN on NT, but can be used against DB's elsewhere through "the miracle of SQL*NET".

I've discovered, though, that (at least in my case), in doing tuning data collection and analysis etc, you'd be well advised to put the repository on your own machine rather than on a remote machine, as contrary as this sounds.

I've found the SQLNET double hops (poll data from the remote instance being studied, drag it back to your desktop machine, fiddle it, then pop it out to another remote server) slows down the business, as opposed to grab data sample, fiddle it, and store it locally on your NT box; I have gotten dramatic improvements in those type of operations by having the OEM instance co-located with where OEM itself is run, it's amazing.

This is also especially true of Oracle Designer in using the Reverse Engineering stuff.

Also, make sure all your connections to the machines being monitored / analyzed have SERVER=DEDICATED entries in the tnsnames file on your OEM box, never use MTS for OEM or Designer.

Annnd, I'd also suggest you create a new entry in /etc/services reserving something like 1528 for your private use and make the appropriate changes to the sqlnet files on the hosts and your OEM box to point to it, so you have your own listener on a separate port from everybody else. Particularly if you do client/server (is anyone still doing that??!) and you tie up the listener for an extensive data collection for tuning, or for reverse engineering in Designer, people will begin lining up outside your office with various sorts of lethal weapons and you may even get complaints about ORA-12154 errors; not to mention, it'll take forever for you to do YOUR stuff, so everybody ends up cranky.

I generally recommend to my dba's to of course set up a listener for normal ops by 'regular people' doing server instance to desktop app connections, a separate listener reserved for SQLNET links between servers (dblinks, etc), a third reserved for DBA administrative use (OEM or other desktop real-time monitoring) and a fourth reserved for DBA use of OEM data collection/special tuning studies and for Designer RE data gathering, both of which are massive consumers of listener bandwidth and generate a lot of network traffic. (Hence the hint to put the OEM repository on the OEM box, not on some remote DB instance.)

If you really want to be nice, put the OEM box in the machine room and put it on the ring (figuratively speaking, meaning the network reserved for inter-server communications, whether it be ATM or FDDI or switched Ethernet, whatever the servers use to talk to each other [NOT the interconnect for OPS!!]). Which leads to the final kibitz-- get a nice fast, fast as you can afford machine and dedicate it to doing OEM data gathering, put it as close in the network hierarchy as you can to the servers, and its life should be devoted to constantly running the OEM management service (it's some kind of database), an Oracle instance to support OEM's repository, and the Designer repository. As much CPU power as you can beg, and also, preferably, a high performance SCSI controller that can do RAID-1 via hardware, a few nice, huge, fast Quantum disks (or anything but Micropolis. are they still in business?) and needless to say, the card supporting the fastest access possible to the internal server network. And a UPS; this thing should run constantly; I invented an entire new family of curse words when a lengthy Designer RE session turned into poo because we had a 1 minute power failure. Likewise you never want the OEM System Management service or the OEM Repository to ever be down.

(And yet another reason to put the thing in the machine room-- you can UPS the hell out of the thing, but if it's remote from the servers it's gathering data from, and any of the hubs, routers, etc in between lose power, well , then its time to invent a second set of new cursewords.) It won't need much of a monitor or video controller though, at least.)

And then, back wherever your office is, a CPU heavy, very very heavy video controllerwise, best available networking, memory heavy, so-so on hard disk, at least 4 Gb, more is better; RAIDing isn't necessary, and a great big monitor, for realtime display / management screens of all your instances, and to deal with Designer RE results and turning them into something readable; this would be your monitor/control station, linking to the grunt in the computer room doing all the data collection. (Real-time monitoring / display using OEM isn't very resource consumptive, it's the data gathering / analysis / recommend phase that gets you, and the RE collection and data mushing phase in Designer.

But a machine in your office should be dedicated to constantly displaying instance status and for dealing with Designer (hey nobody's made of money, you can take a break from real-time status displays to CASE the joint!) (so to speak)

And of course a PC for you to run Office /whatever, whatever other goo your organization insists on, like incomprehensible time reporting apps, to read/ resolve / enter REMEDY tickets, terminal emulation, all that stuff, Web access to Metalink, OTN, etc.

Take this advice or leave it, it was learned by me the hard way over years, and trust me, it will save you so much grief.

Well good luck with everything.

email me if you have any problems or need a detailed "why I need all this money" argument to give the muckymucks, or have any problems with OEM or Designer.

RSH. "Daniel_Bryant" <danielbryant_at_cobbk12.org> wrote in message news:85a5053.0202270955.4f096782_at_posting.google.com...
> I have a DB on a Sun Solaris Server, and one on an Win NT Server, and
> I want to run the Tuning, Diagnostics Packs, but DocID:Note 114959.1
> on MetalLink says "Tuning/Diag only available on Windows NT"... My
> CD's from Oracle (8.1.6) for the Sun Solaris came with the NT version
> of Tuning/Diag Packs. Do I just install the OEM on my local PC
> running Win 2000 and add the Sun DB and Windows NT DB to the OEM ?
>
> Thanks in Advance !
Received on Thu Feb 28 2002 - 04:22:18 CST