January 22, 1998

(Last modified December 5, 1999)

Creating a New Database as a Copy of Another

1. Get a listing of all files currently in the database to be copied. Use ll, for example,
ll /*/oradata/<sid>
where <sid> is the database name, such as, testm, tests, devm, etc.

2. Follow the steps in >Creating a New Database=

(I:\INFO\SOFTWARE\FIMS\NewDB) through step 3 (creating symbolic links), you
do not need to apply patches nor run ADE or Discover 3.0 scripts.

3. Determine where the new files will be located. The new files must be identical in
number and size to the ones being copied. Use the same naming convention for the
paths, /*/oradata/<sid>, and the files.

4. You will need to have a init<sid>.ora and config<sid>.ora file for the new database.
You might want to copy these from the source database and make the necessary
changes. If one already exists, verify that the parameters are correct. In particular,
the location of the control files in the config<sid>.ora file.

5. Create a new control file of the source database. Enter SQL*PLUS and connect as
system. Enter:
Alter database backup controlfile to trace;

6. Locate the trace created and move to

/u01/app/oracle/admin/<sid>/create/ccf<sid>.sql
The file will be the last ora_NNNN.trc file written to
/u01/app/oracle/admin/<sid>/udump.

7. Modify the ccf<sid>.sql for the target database:

1. Changing all paths to the new target database paths.
2. Delete all extraneous comments, start with line 1 down to the
ASTARTUP NOMOUNT@. Do not delete the ASTARTUP
NOMOUNT@. Delete the ARECOVER DATABASE@ at the bottom.
3. Modify the ACREATE CONTROLFILE@ command. Change the
word AREUSE@ to ASET@ and ANORESETLOGS@ to
ARESETLOGS@. Make sure that ANOARCHIVELOG@ is
specified. Also change datebase name.
4. Remove AALTER DATABASE OPEN@.

8. Delete obsolete files in :

/u01/app/oracle/admin/<sid>/*dump
/u08/backup/archive/<sid>

I:\INFO\SOFWARE\FIMS\CopyDB
Page 1
 /u14um/archive_old/<sid>
/u13/app/applmgr/common/log<sid>
/u13/app/applmgr/common/out<sid>

9. Shutdown normal the database being copied.

10. 1. Using UNIX cp command:

(1) Use UNIX cp to copy the files to the new location. You should take a
backup of the source database as a precaution. If the files currently
exists, you might want to delete the target files and use >cp -i= to
perform the copy.
(2) After the copies complete, delete the *.ctl files from the target database.
There should be three.
2. Using restore from tape backup to target files:
(1) Go into the OmniBack on-line GUI panel to determine from which
session you want to restore. Refer to the OmniBack documentation for
accessing the OmniBack GUI panel. Then click on Monitor / View /
Previous Sessions / All Sessions. The Session ID is in yyyy/mm/dd-nn
format. For example, 1998/10/05-1.
(2) From an Unix prompt, enter
/opt/omni/bin/omnidb -session <session id> -detail
where the <session id> is the one obtained in step 4. The listing will
give you the HOST:MOUNT-POINT LABEL needed for the omnir
command. For example,
omnidb -session 1998/10/05-1 -detail
in the listing, you will see
Object name: fims.fims.org:/u07 >fims Weekly [/u07] =
for the backup of mount point /u07.
(3) Go to the /etc/opt/omni/restores directory for examples of past restores,
such as restore_tests_diff.sh. Be sure to verify the database=s current
file locations (step 2 above) and modify as needed. Modify the example
with the correct label id and session id, as determined above.
(4) Check that all files have been restored. There have been problems with
OminBack skipping some files.
(5) After the restore completes, delete the *.ctl files from the target
database. There should be three.
3. Using restore from a hotbackup tape:
(1) Go into the OmniBack on-line GUI panel to determine from which
session you want to restore. Refer to the OmniBack documentation for
accessing the OmniBack GUI panel. Then click on Monitor / View /
Previous Sessions / All Sessions. The Session ID is in yyyy/mm/dd-nn
format. For example, 1999/02/19-1.
(2) From an Unix prompt, enter
omnidb -session <session id> -detail

I:\INFO\SOFWARE\FIMS\CopyDB
Page 2
 where the <session id> is the one obtained in step 4. The listing will
give you the HOST:MOUNT-POINT LABEL needed for the omnir
command. For example,
omnidb -session 1999/02/19-1 -detail
in the listing, you will see
Object name: fims.fims.org:/u14um >hotbackup_prods=
(3) Go to the /etc/opt/omni/restores directory for examples of past restores,
such as restore_soft_diff.sh. This will restore the hotbackup to
/u14um/hotbackup/soft.
(4) Now copy the .dbf and the .log files from /u14/hotbackup/<sid id> to
the correct database locations. Be sure to verify the database=s
current file locations (step 2 above) and modify as needed. For
example, see /home/oracle/copy.prods.soft.sh. Modify the example with
the correct label id and session id, as determined above.
(5) Check that all files have been restored. There have been problems with
OminBack skipping some files.

11. Enter >echo $ORACLE_SID= to confirm that ORACLE_SID is set to the new
database.

12. Make sure that $ORACLE_HOME is set to the oracle home of the database from
which you are copying.

13. The database you are copying from has to be down before the following will work.

14. After the copy completes, perform the following step:

1. cd /u01/app/oracle/admin/<sid>/create
2. svrmgrl
3. connect internal
4. @ccf<sid>.sql
5. select * from v$database; (to verify database name)
6. select * from v$datafile; (to verify database files)
7. select * from v$logfile; (to verify log files)
8. If you are recovering from a hotbackup, follow the set set of steps. If not, skip
to the >alter database open resetlogs=;
9. Alter database recover until cancel using backup controlfile;
***Note: You can also use >until time <date>= or no until, which will apply
all
archive logs.
10. Alter database recover logfile ><full path of logfile>=;
***Note: Be sure that all logfiles needed have mode 644.
For example:

SVRMGR> connect internal;

Connected to an idle instance.
SVRMGR> @ccfsoft.sql

I:\INFO\SOFWARE\FIMS\CopyDB
Page 3
ORACLE instance started.
Total System Global Area 38481164 bytes
Fixed Size 38980 bytes
Variable Size 33903816 bytes
Database Buffers 4505600 bytes
Redo Buffers 32768 bytes
Statement processed.
SVRMGR> alter database recover until cancel using backup controlfile;
alter database recover until cancel using backup controlfile
*
ORA-00279: Change 3784194 generated at 02/19/99 01:30:08 needed for thread 1
ORA-00289: Suggestion : /u08/backup/archive/soft/T0001S0000002697.ARC
ORA-00280: Change 3784194 for thread 1 is in sequence #2697
SVRMGR> alter database recover logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC';
alter database recover logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC'
*
ORA-00279: Change 3784294 generated at 02/19/99 01:59:03 needed for thread 1
ORA-00289: Suggestion : /u08/backup/archive/soft/T0001S0000002698.ARC
ORA-00280: Change 3784294 for thread 1 is in sequence #2698
ORA-00278: Logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC' no longer needed for this recovery
SVRMGR> alter database recover logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC';
alter database recover logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC'
*
ORA-00279: Change 3784294 generated at 02/19/99 01:59:03 needed for thread 1
ORA-00289: Suggestion : /u08/backup/archive/soft/T0001S0000002698.ARC
ORA-00280: Change 3784294 for thread 1 is in sequence #2698
ORA-00278: Logfile '/u14um/hotbackup/soft/T0001S0000002697.ARC' no longer needed for this recovery
:
:
SVRMGR> alter database recover cancel;
Statement processed.
11. Alter database open resetlogs;

15. Shutdown and backup the new database.

16. Change passwords for the following (see /home/oracle/security/passwords/alter_users.sql):

1. system and sys
2. apps and applsys in Oracle applications and then via sqlplus. No other users may
be on system when changed apps and applsys.
3. xx<mc|sa>_<short name>
4. alter database rename global_name to <sid>.world. To verify, select * from
global_name.

17. Cancel all >Pending= and >Inactive= concurrent request before starting the
concurrent managers.

18. Change profile system option >Site name= to <Salem|Marion> <sid>.

19. Change profile system option >Utilities:Diagnotics= to yes for >US HRMS
Manager= and >Marion HRMS Manager=.

I:\INFO\SOFWARE\FIMS\CopyDB
Page 4
20. Deactivate scheduled alert managers. Login with the responsibility of >Alerts Manager
GUI= and navigate to Request / Schedule.

21. In non-production databases, activate the following responsibilities for all FIMS
developers: >System Administrator GUI=, >Application Developer GUI= and
>Alert Manager GUI=. The description will be >Data Center FIMS Support
Staff= or >Contract Programmer=.

22. If you want the database to be in archivelog mode, the perform the following steps:
(1) make sure that ORACLE_SID is set to the right database
(2) shutdown the database normally (not immediate)
(3) svrmgrl
connect internal;
startup mount exclusive;
alter database archivelog;
shutdown normal;
(4) You must take a backup of the database now, because you will not be able
to perform recovery by using a backup taken prior to changing the mode to
or from noarchivelog.

23. Update fims_training\FIMSDOCS\database.wpd.

24. If you copy the production APPL_TOP to test or development, first save the current
test or development APPL_TOP. After the copy completes, move back in the
following files / directories from the saved copy:
(1) install/log and install/out directories
(2) the custom (xx..) directories
(3) the APP<sid>.env files
(4) the applptch.txt and applptch.tmp files
(5) recreate the symbolic links (as identified in the
I:\info\software\fims\patches documentation file)

I:\INFO\SOFWARE\FIMS\CopyDB
Page 5