Oracle 11g Create Parameter file from memory and Hot Patch(原创)

Creating a Parameter File from Memory
You can now create a text initialization parameter file (PFILE) or a server parameter file (SPFILE) from the system-wide parameters currently in use by the instance. Here’s how you generate the initialization parameter file from the settings in memory:
SQL> create pfile from memory;
File created.
You can also create an SPFILE from the parameter settings in memory, as follows:
SQL> create spfile from memory;
File created.
You can use this ability to create a text parameter file or an SPFILE from memory when you can’t access your parameter file because it’s corrupted or lost. The following example demonstrates this:
SQL> create pfile from spfile;
create pfile from spfile
*
ERROR at line 1:
ORA-01565: error in identifying file
'/u01/app/oracle/product/11.1/db_1/dbs/spfileauxdb.ora'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
The example shows that you can’t create a new parameter file from the SPFILE because the database can’t find the SPFILE. When you lose an SPFILE, it’s easy to recover from it because of the new ability to re-create the SPFILE from memory. If the instance can’t find the parameter file and you therefore can’t create the new parameter file, you can execute the create pfile from memory statement instead to re-create an init.ora file from memory. The new file that you create from memory will have values for all the 150 or so initialization parameters, even though you haven’t set the values for most of them in your parameter file when starting the database. Oracle uses the default value for all the parameters that you ignored.
Hot Patching
Traditional patching of database server code always involves downtime for the database. While the downtime doesn’t pose any problems on a test database, it’s not so easy when you are working with production databases. Hot patching (or online patching) enables you to apply bug fixes or diagnostic patches on a live database, without incurring any downtime. Live application of patches makes a lot of sense, especially when you are dealing with a small bug fix or a diagnostic patch. The opatch command-line utility lets you perform online patching. Using opatch, you can install, enable, and disable patches. You can continue to use the opatch utility as in the previous release to perform normal offline code patching. In Oracle Database 11g, you can use opatch to perform online patching as well.
Benefits of Hot Patching
Hot patching with the opatch utility offers the following benefits: No need to restart the database, thus preventing any downtime for patching. Quick installation and de-installation of patches. Unlike conventional patches, hot patches take seconds, not minutes to apply.
Automatic listing in patch inventory.
Ability to work in an Oracle RAC environment, which lets you perform a rolling patch application. You don’t have to worry about whether the hot patch can be applied as a rolling upgrade or as an upgrade. Hot patches persist across instance shutdowns.
Installing a Hot Patch
As mentioned earlier, you use the opatch utility to perform an online patching. Oracle automatically detects any conflicts between two hot patches. You can issue the $ORACLE_HOME/OPatch/opatch command to determine if a patch is a hot patch:
$ opatch query -is_online_patch <patch location>
You can also use this variant of the previous command for the same purpose:
$ opatch query -is_online_patch <patch location> -all
Once you confirm that a patch is indeed an online patch, you can use the opatch utility to perform the patching.
Considerations
Currently, hot patching is available only on some platforms such as Linux x86, Linux x86-64, and Solaris SPARC64. The opatch utility does consume extra memory depending on the size of the patch and the number of currently running concurrent Oracle processes. You’ll need a minimum of one OS page of memory for each running Oracle process when you apply a patch. An OS page usually is 4 KB on a Linux x86 server and 8 KB on a Solaris SPARC64 system. If there are 500 Oracle concurrent processes running on a Solaris SPARC64 server, for example, you can expect to need only about 4 MB of memory for applying a small patch online.

 

参考至: 《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》
本文原创，转载请注明出处、作者

如有错误，欢迎指正

邮箱:[e-mail]