This post is the third of the series of ten posts that explore some of the Oracle Universal Installer (OUI), Network Assistant (NETCA), Database Creation Assistant (DBCA), Database Upgrade Assistant (DBUA) and other syntaxes you can use to script or speed up Oracle Installations. The complete series should look like this:

1. Installation of 10.2 And 11.1 Databases
2. Patches of 10.2 And 11.1 databases
3. Cloning Software and databases (this post!)
4. Installing a 10.2 RAC Database
5. Add a Node to a 10.2 RAC database
6. Remove a Node from a 10.2 RAC database
7. Install a 11.1 RAC Database
8. Add a Node to a 11.1 RAC database
9. Remove a Node from a 11.1 RAC database
10. A ton of other stuff you should know

In the first post and second post, we focused on how to leverage these tool to perform a standard installation and apply patches on top of 10.2 and 11.1 databases. This post will dig into the cloning features of both the Universal Install (OUI) and the Database Configuration Assistant (DBCA).

Foreword

The Universal Install and Database Configuration Assistant Cloning features enable you to:

• Install the database software once, apply to it all the patches you need, including Patch Set, CPU, and One-Off patches, and create a “Gold Image” of that software you’ll be able to deploy on all the servers you need as soon as they run the same Operating System.
• Create a database, apply all the scripts you need including the catupgrd.sql, the cpu.sql or any other script associated with patches. You can also run any script that will create a skeleton for installing your application, create tablespaces, create objects, or set parameters. Once done, you’ll be able to create a template from that database and to use it on any servers that run the same operating system and the same database software.

How to clone Oracle database software

You can refer to the product documentation for the whole database software cloning process:

• Oracle Universal Installer and OPatch User’s Guide 10g Release 2 (10.2), Chapter 7 Oracle Software Cloning Using Oracle Universal Installer
• Oracle Universal Installer and OPatch User’s Guide 11g Release 1 (11.1), Chapter 6 Cloning Oracle Software

The process is straightforward and consists of three different steps:

(more…)

This post is the second in a series of ten posts exploring some of the Oracle Universal Installer (OUI), Network Assistant (NETCA), Database Creation Assistant (DBCA), Database Upgrade Assistant (DBUA), and many more syntaxes you can use to script or speed up Oracle Installations. The complete series should look like:

1. Installation of 10.2 And 11.1 Databases
2. Patching 10.2 And 11.1 databases (this post!)
3. Cloning Software and Databases
4. Installing a 10.2 RAC Database
5. Add a Node to a 10.2 RAC database
6. Remove a Node from a 10.2 RAC database
7. Install a 11.1 RAC Database
8. Add a Node to a 11.1 RAC database
9. Remove a Node from a 11.1 RAC database
10. A ton of other stuff you should know

In the first post, you can find syntaxes to install a 10.2 or a 11.1 database, and how to apply a Patch Set on top of them. This post is way shorter and digs into a couple OPatch, DBUA, and OUI syntaxes. It explains how to apply a one-off patch, how to upgrade a database and how to uninstall a previous ORACLE_HOME.

Foreword

There are basically two ways to upgrade your Oracle Database Software to a new Patch Set level:

1. The In-Place Way: reuse the same ORACLE_HOME
2. The Out-of-Place Way necessitates that you create a new ORACLE_HOME for the new Patch Set

If the 10g OFA standard contains only the Base Release version, you will be able to perform an In-Place Upgrade. Thi approach, however, has several drawbacks:

• It requires that you stop all the components (Listeners, ASM, Instances, Database Console) during the software upgrade.
• It doesn’t leave the previous ORACLE_HOME install intact, and makes more complex the build of a rollback scenario.
• If you’ve installed a one-off patch, it is very likely the patchset will erase them, but Inventory will keep track of them.

For all those reasons, it’s safer to use a new ORACLE_HOME and so I won’t cover how to perform an In-Place update. Actually it’s not really different, so you should easily be able to build that scenario by yourself. And if you think: “Well, what the use of keeping only the major Database version in the OFA standard if you advise using a new ORACLE_HOME ?”, the answer is: “Once you’ve release the 10.2.0.3 ORACLE_HOME to use a 10.2.0.4 ORACLE_HOME, with that changed in the OFA standard, you’ll be able to use that ORACLE_HOME for the next Patch Set without reinstalling the software and the names will stay consistent!”. But enough of this foreword.

(more…)

This post is the first of a series of ten posts that will explore some of the Oracle Universal Installer (OUI), Network Assistant (NETCA), Database Creation Assistant (DBCA), Database Upgrade Assistant (DBUA), and many more syntaxes you can use to script or speed up Oracle Installations. The agenda should follow the one below:

1. Installation Of 10.2 And 11.1 Databases (this post!)
2. Patching 10.2 And 11.1 Databases
3. Cloning Software and Databases
4. Installing a 10.2 RAC Database
5. Add a Node to a 10.2 RAC database
6. Remove a Node from a 10.2 RAC database
7. Install a 11.1 RAC Database
8. Add a Node to a 11.1 RAC database
9. Remove a Node from a 11.1 RAC database
10. A ton of other stuff you should know

Actually, I may have to split the post #10 into ten more posts to cover all the other syntaxes you could use with Oracle Enterprise Manager, Application Server, or on Windows. Anyway, for now let’s focus on the very beginning: how to install 10.2 or 11.1 non-RAC database; how to apply the latest patch set; and how to create a instance database from a template.

Foreword

First, just because it’s on the Internet doesn’t make it true — even if it’s on the Pythian Blog. There will be a lot of syntaxes in those ten posts and even if they’ve been all tested, (1) the testing conditions are probably very different from your environment, and (2) the commands have been customized so that they appear generic. Be careful; it’s very likely that the syntaxes will be wrong for you. Test them yourself on a test environment and don’t execute them if you don’t understand what every part of them is supposed to do.

One of the reasons for these posts is that it’s kind of difficult to figure out by yourself how you should run one particular tool. The information is spread across the reference manuals, the response files, the online help, and sometimes Oracle Metalink or people that managed to make it work.

In addition, if the syntax looks similar for all the tools, they differ more than we can guess first. Let’s take some examples to illustrate that and to begin with the syntaxes:

(more…)