| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> SUMMARY: Quickest way to manually create a new database ?
In article <330ac978.5901416_at_news.ruca.ua.ac.be>,
lujo_at_ruca.ua.ac.be (Ludo Joris) writes:
>Do you mean you do not want to use Oracle Installer?
Nope, I don't trust that installer as far as I can throw it...
>Create/Upgrade Database Objects. It will prompt you for a new
>SID name (and many other things).
You don't have to a lot of work in the "manual" route - just some file editing and SQL script running.
>Had to generate new tnsnames.ora, sqlnet.ora and listener.ora files
>with Network Manager (on a PC with Windows) for SQL*Net.
I just extended those files by cutting and pasting the entries with the new database names. In fact, I never created those *.ora files with the Network Manager in the first place - it is *utterly outrageous* that there isn't a "Network Manager for UNIX" when you buy UNIX Oracle !!! I do NOT want to run software on a PC to configure a UNIX system thank you very much...
I got my *.ora files from the UK Supoort Line (they are also available for download from the password-protected www.oracle.co.uk WWW site - quite why good sample *.ora files aren't actually SHIPPED with UNIX Oracle is beyond me !).
>The second instance is up and running, the listener too.
Ditto here, although I'm about to bump up my kernel limits for shared memory segments and semaphores because of the two instances instead of one.
>Now I'm wondering if i have left out something imporant by using
>Oracle Installer to create a second instance!
It probably does these steps, which I gleaned from various helpful replies to my original posting [<DB1> = first original instance name, <DB2> = second one]:
cd $ORACLE_HOME/dbs
cp config<DB1>.ora config<DB2>.ora
cp crdb<DB1>.ora crdb<DB2>.ora
cp crdb2<DB1>.ora crdb2<DB2>.ora
cp init<DB1>.ora init<DB2>.ora
Editng required:
config<DB2>.ora:
- Change paths of control_files to the three new locations you want to put them
in (Oracle recommend three different disks, which is probably overkill !).
- Change background_dump_dest, core_dump_dest, user_dump_dest (and maybe
log_archive_dest if you've uncommented it) to point to new locations.
- VERY IMPORTANT: Change db_name to <DB2> !!!
crdb<DB2>.sql:
- Change various paths to new locations, including:
crdb2<DB2>.sql (this script is critical and NOT mentioned in the manual): - Change all references of <DB1> to <DB2> instead. - Paths for create tablespace rbs|temp|tools|users commands need changing.
init<DB2>.ora:
- ifile needs to include config<DB2>.ora
- Change any references (e.g. for mts_service - you do use the Multi-Threaded
Server of course...any sane person does !) of <DB1> to <DB2>.
- You might want to tweak various values here because you might exceed your
kernel's shared memory segments or semaphores if you give it the same
config as the first instance.
$TNS_ADMIN/listener.ora:
- Create another SID entry for <DB2> in the SID_LIST_LISTENER structure.
$TNS_ADMIN/tnsnames.ora:
- Create another named service (the one you specified for mts_service in
init<DB2>.ora) and use the <DB2> SID.
On the Oracle server (doesn't need the first instance running, though it's useful to have it running so you can make sure both instances can run simultaneously without hitting resource limits), do this as the Oracle user:
IMPORTANT STEP: $ export ORACLE_SID=<DB2>
[if you don't properly set ORACLE_SID, you could kiss goodbye to your first instance !]
$ svrmgrl
SVRMGR> @?/dbs/crdb<DB2>.sql SVRMGR> @?/dbs/crdb2<DB2>.sql (this was never specified in the manual) SVRMGR> @?/rdbms/admin/catproc.sql
The resultant database should now be ready and you should have new ora*<DB2> processes running on your machine.
You should add a <DB2> entry to /etc/oratab to make sure the new instance gets shutdown and restarted properly in the future. I would advise you to check this out once you've editing /etc/oratab with:
$ dbshut $ lsnrctl stop $ lsnrctl start $ dbstart
One thing to note - the SQL scripts *fail* if they are run twice (to be expected really) and the whole thing is very fussy about not overwriting existing files, so if you make a mess of things, you must delete *every* created file associated with <DB2> before starting from the beginning. If you put the <DB2> files on a separate disk from <DB1> (you definitely should do this), then it's easy enough to have a shell script do a find -type f -exec rm to trash the files before doing it again (I did about 4 runs until I was happy).
FOR HEAVEN'S SAKE - back up your existing first instance before trying this... it's a highly risky process and I take no responsibility for any mistakes I have made in the above posting (or any mistakes you might make in following the instructions). USE THESE INSTRUCTIONS AT YOUR OWN RISK.
Richard K. Lloyd, E-mail: rkl_at_csc.liv.ac.uk Computer Science Dept., WWW: http://www.csc.liv.ac.uk/~rkl/Liverpool University,
 |
 |