RE: Oracle EM Provisioning/patching pack
Date: Thu, 7 May 2009 14:55:26 -0400
Message-ID: <0684DA55864E404F8AD2E2EBDFD557DA02B95B9F_at_JAXMSG01.crowley.com>
I mentioned something when I commented. Don't use it for CPU patching because not all our servers are licensed from the provisioning pack, when they are, I'll look into it again.
The purpose of the existing pack was for 'db owners' to duplicate there own databases from production freeing me up, (this is termed clone in the pack). But what I found out was that this 'db owner' had to rename all the files! Which could be many.
For we inherited an OFA architecture /u01/oradata/<sid_prod1>... /u20/oradata/<sid_prod1>, <sid_prod2>, <sid_prod3>... etc.
So on dev or acceptance it was /u01/oradata/<sid_test1>, etc. So the 'db owner' had to rename every datafile from sid_prod1 to sid_test1!
With Rman duplicate, you use the convert parameters in the init file; simply /u01/oradata/sid_test1, /u01/oradata/sid_prod1. done. analogous for the log files. Once the first one is finished, the hardest thing is to ftp the files, then its 'basically' one command 'duplicate target to sid_test1'. The rest is cleanup... like directories or dblinks or passwords etc.
The provisioning pack would take care of the ftp, but the tediousness of renaming every file has thus far prevented us from using it. We are asking for all the servers to have it in the next budget, so I may try to utilize it for CPU patching, but it might prove to soon to justify the expense for such little gain.
Joel Patterson
Database Administrator
904 727-2546
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Herring Dave - dherri
Sent: Wednesday, May 06, 2009 1:24 PM
To: mzito_at_gridapp.com; oracle-l_at_freelists.org
Subject: RE: Oracle EM Provisioning/patching pack
Matt,
We're starting to use OEM Provisioning for 10.2.0.4 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. | www.acxiom.com
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Matthew Zito Sent: Tuesday, May 05, 2009 7:41 AM
To: oracle-l_at_freelists.org
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?
Thanks,
Matt
--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito_at_gridapp.com
http://www.gridapp.com
The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.
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.
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 07 2009 - 13:55:26 CDT