Re: Conceptually cloning an oracle home
- From: "Jack van Zanen" <jack@xxxxxxxxxxxx>
- To: orcl@xxxxxxxxxxx
- Date: Sat, 21 Jun 2008 15:13:05 +1000
opatch lsinventory list the one of patches and cpu patches that have been
installed on top of whatever version of oracle. has nothing to do with the
database options.
If you need the Oracle homes to be exactly the same I think you need to
install the correct oracle version you want and work your way through the
list of OPATCH LSINVENTORY and install them all.
Sounds like a very tedious job to me whichever way you look at it and after
going through such an exercise and still be on 10.1 sounds to me like a
waste of time. BUT if the people that sign the check want this and can not
be convinced otherwsie.........
Jack
2008/6/21 Bob <orcl@xxxxxxxxxxx>:
> OS= HP-UX 11
> Oracle version 10.1.0.4
>
> I need to move a bunch of oracle homes to new filesystems. The problem is
> matching up the installed options exactly. One would think, install the new
> version via custom install, choose from the pick list - the primary
> features (partitioning, data mining, label security etc) What happens is...
> when I do a opatch lsinventory details > optionlist.txt
> and compare to the production install, there are huge number of items that
> are in prod but not in the new install. Even doing a full "enterprise"
> install, there is a long list of missing options/features. I need to match
> the production home's options/features *exactly*
>
> The measuring tool is "opatch details" . Although I've dumped the
> "installed products" from OUI and there is a similar huge list of missing
> features.
>
> I know going forward, 10.2 ... and even more stable in 11.* there is the
> ability to actually "clone" the home. So, conceptually that's what I need to
> do. I have about 50 homes to move... so I need to get a repeatable process.
>
> Upgrading the databases is not an option. Finding a new job is not an
> option. Has anyone done this, or has any ideas?
>
> Thanks
> Bob
>
> --
> "Oracle error messages being what they are, do not
> highlight the correct cause of fault, but will identify
> some other error located close to where the real fault lies."
>
>
>
--
J.A. van Zanen
Other related posts:
