Oracle Database Hidden Parameters

REM Script for getting undocumented init.ora
REM
COLUMN parameter FORMAT a37
COLUMN description FORMAT a30 WORD_WRAPPED
COLUMN "Session Value" FORMAT a10
COLUMN "Instance Value" FORMAT a10
SET LINES 100
SET PAGES 0
SPOOL _hidden_ora_params.txt
SELECT
a.ksppinm "Parameter",
a.ksppdesc "Description",
b.ksppstvl "Session Value",
c.ksppstvl "Instance Value"
FROM
x$ksppi a,
x$ksppcv b,
x$ksppsv c
WHERE
a.indx = b.indx
AND a.indx = c.indx
AND a.ksppinm LIKE '/_%' escape '/'
/
SPOOL OFF
SET LINES 80 PAGES 20
CLEAR COLUMNS

How to Clone ORACLE_HOME 10.2

Cloning an Oracle Home

Cloning an Oracle home involves creating a copy of the Oracle home and then configuring it for a new environment. If you are performing multiple Oracle Database installations, then you may want to use this method to create each Oracle home, because copying files from an existing Oracle Database installation takes less time than creating a new version of them. This method is also useful if the Oracle home that you are cloning has had patches applied to it. When you clone this Oracle home, the new Oracle home will have the patch updates as well.
Note:
In addition to cloning an Oracle home, you can clone individual Oracle Database installations by using Enterprise Manager Database Control. Oracle Database Administrator's Guide provides detailed information about cloning Oracle Database installations and Oracle homes.
To clone an Oracle home:
1. Verify that the installation of Oracle Database that you want to clone has been successful.
You can do this by reviewing the installActionsdate_time.log file for the installation session, which is normally located in the /orainventory_location/logs directory.
If you have installed patches, then you can check their status by running the following commands:
$ $ORACLE_HOME/OPatch ORACLE_HOME=ORACLE_HOME_using_patch
$ $ORACLE_HOME/OPatch opatch lsinventory


2. Stop all processes related to the Oracle home. Refer to the "Removing Oracle Software" section for more information on stopping the processes for an Oracle home.
3. Create a ZIP file with the Oracle home (but not Oracle base) directory.
For example, if the source Oracle installation is in the /u01/app/oracle/product/10.2.0/db_1, then you zip the db_1 directory by using the following command:
# zip -r db_1.zip /u01/app/oracle/product/10.2.0/db_1


Leave out the admin, flash_recovery_area, and oradata directories that are in the 10.2.0 directory. These directories will be created in the target installation later, when you create a new database there.
4. Copy the ZIP file to the root directory of the target computer.
5. Extract the ZIP file contents by using the following command:
# unzip -d / db_1.zip


6. Repeat steps 4 and 5 for each computer where you want to clone the Oracle home, unless the Oracle home is on a shared storage device.
7. On the target computer, change directory to the unzipped Oracle home directory, and remove all the .ora (*.ora) files present in the unzipped $ORACLE_HOME/network/admin directory.
8. From the $ORACLE_HOME/oui/bin directory, run Oracle Universal Installer in clone mode for the unzipped Oracle home. Use the following syntax:
$ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME="target location" ORACLE_HOME_NAME="unique_name_on node" [-responseFile full_directory_path]


For example:
$ORACLE_HOME/oui/bin/runInstaller -silent -clone ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_1" ORACLE_HOME_NAME="db_1"


The -responseFile parameter is optional. You can supply clone-time parameters on the command line or by using the response file named on the command line.
Oracle Universal Installer starts, and then records the cloning actions in the cloneActionstimestamp.log file. This log file is normally located in /orainventory_location/logs directory.
9. To create a new database for the newly cloned Oracle home, run Database Configuration Assistant as follows:
$ cd $ORACLE_HOME/bin
$ ./dbca


10. To configure connection information for the new database, run Net Configuration Assistant.
$ cd $ORACLE_HOME/bin
$ ./netca

The Future of DBMS and Database Computing and How Postgres will do to Oracle What Linux has done to Unix vendors.

Database Management Systems (DBMS) have been with us for several decades now, significant progress has been made in DBMS software evolution, the database management software is become ever more powerful, scaling horizontally and vertically. Database software vendors such as Oracle, Sybase, IBM, Informix keep updating their software offerings with more features being added almost on daily basis. With the database computing consolidating in the hand of single company - Oracle the logical question comes to mind what is next? Will Oracle once again reinvent the database computing or fall inevitable victim of GNU software projects. We have witnessed Linux taking over server operating systems computing and slowly dissolving and assimilating away all proprietary Unix offerings (AIX, HP, Tru64….and others), the list is ever shrinking and eventually even the last big four (AIX, HP-UX, Sun, Tru64) will succumb to overwhelming power of GNU Development. Will this happened in the database world? Of course, most of us blessed with the “vision” saw the inevitability of this evolution back in early nineties with the advent of Linux. GNU databases will overpower traditional DBMS vendors in terms of scalability, costs, performance and features. Some already exist and some have not been invented yet. So who will conquer the ever powerful database vendors such as Oracle and others? The contender is already here – PostgreSQL. A distant relative of Oracle it will come back and claim the throne of database computing.

Inevitability. PostgreSQL or any other GNU/BSD database offering will not conquer proprietary database single handedly but rather though a process of “computing evolution” i.e. our perception of database and DBMS will evolve and along with propelling GNU database software to the commanding role. There are several evolutionary elements that needed to be present in order for GNU software offering become the dominant platform of choice.

1. Project vs. Product. The GNU software in our case PostgreSQL has to be a “project” and not a “product”. Seems confusing at first but bear with me here, lets compare two database offerings PostgreSQL and MySQL one is a “project” and the other is a product. MySQL is a “product” that is owned by a software company MySQL AB with available source code. “Product” can be sold, discontinues assimilated etc…Speaking of which that probably exactly what will happened to MySQL after the recent acquisition by Sun Microsystems.

More will follow…….