RE: Oracle EM Provisioning/patching pack

  • From: "Herring Dave - dherri" <Dave.Herring@xxxxxxxxxx>
  • To: <mzito@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 6 May 2009 12:23:31 -0500


We're starting to use OEM Provisioning for databases under Linux RHEL 
4.x.  We've successfully cloned Oracle homes and applied patches (mostly 
CPU/security ones) to a number of databases.  There were some issues that note 
427577.1 didn't address, but we got past them and all seems fine now.

With something like this, I prefer to understand both sides of the street, as 
in the manual and "automated" methods.  I'm not going to try to convince 
management to license something for production use, just so I can "play" with 
it.  But I can sure evaluate it in development and if valuable, do my best to 
have it used in production.  

It just seems to me that it's becoming more and more important to understand 
how to perform DBA tasks on the front and back ends.  One perhaps odd reason is 
that Oracle's doc seems to include more and more examples using GUI tools.  If 
that's the only example I've got, I can run the GUI, tracing behind the scenes 
to find out what's really going on so when the GUI isn't available (or doesn't 
work right), I can still get my job done.

To add to the odd mix, we use OEM GC extensively, with all Oracle services and 
servers monitored through OEM, along with all of our DBA admin jobs run out of 
OEM Jobs.  But for a performance problem, I prefer using SQL*Plus Worksheet 
with home-grown scripts.  For me, nothing's better than having my full, split 
screen with scrollable input and output (I use SQL Developer for 10g or later 
commands like PURGE).

David C. Herring  | DBA, Acxiom Automotive

630-944-4762 office | 630-430-5988 cell | 630-944-4989 fax
1501 Opus Pl | Downers Grove, IL, 60515 | U.S.A. |

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Matthew Zito
Sent: Tuesday, May 05, 2009 7:41 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Oracle EM Provisioning/patching pack

Hey all,

The recent thread on OEM's pluses and minuses got me thinking, but I didn't 
want to completely hijack the thread, so I figured I'd start a new one.  It 
seems like most people use OEM/GC for day-to-day DBA activities - monitoring, 
checking utilization, running basic database commands, and for performance 
tuning, basically the tuning and diagnostic pack.

I'm curious as to why no one mentioned the provisioning pack, which Oracle 
markets as a solution for patching, database creation, cloning, etc.  Is it too 
expensive?  Does it not work?  Are patching and deployment just not a problem 
for the folks on this list?  What about RAC - it's supposed to be able to do 
RAC deployment, has anyone tried that?

As full disclosure, my company makes a software product that, among many other 
things, patches database, deploys RAC clusters, automates upgrades, etc.  The 
reason I'm asking is when we're meeting with companies at trade shows, etc., a 
commonly heard refrain is, "Oh, OEM provisioning pack does all that stuff".  
Once we dig into it a bit, though, they've usually never tried it, or don't run 
OEM at all.

So, I figured I'd ask the list- have you ever used the provisioning pack, and 
what did you think?  If you don't use it, why not?  If people would prefer to 
email me off-list, I'll aggregate the info, anonymize it, and send it back to 
the list?


Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.


Other related posts: