Migrating from Single Instance to Parallel Server
This chapter describes database conversion: how to convert from a single instance Oracle7 database to a multi-instance Oracle7 database using the parallel server option.
The chapter is organized as follows:
Overview
The present chapter explains how to enable your database structure to support multiple instances. It can also prepare you to start a project with a single instance Oracle7 database, while being ready to migrate to multi-instance in the future. In addition, it can help you extend an existing OPS configuration to additional nodes.
Attention: Before using this chapter to convert to a multi-instance database, use the Oracle7 Server Migration manual to perform any necessary upgrade of the Oracle Server. That manual also provides information on upgrading and downgrading in replicated systems.
Deciding to Convert
This section describes:
Reasons to Convert
You may wish to convert to a multi-instance database for the following reasons:
- You are already running OPS, but want to extend your database to include more nodes.
- You have enough nodes specified, but need to bring the other nodes online.
Reasons Not to Convert
You should not attempt to convert to a multi-instance database in the following situations:
- You are using a file system which is not shared.
- Your application was not designed for parallel processing; you need to examine your application more.
- You are not using a supported configuration (of shared disks, and so on).
Preparing to Convert
This section describes:
Hardware and Software Requirements
To convert to a multi-instance database you must have:
- a supported hardware and OS software configuration
- license for Oracle Parallel Server
- Oracle Server running on all nodes
- Oracle Parallel Server linked in
Converting the Application from Single- to Multi-instance
Just making your database run in parallel does not automatically mean that you have effectively implemented parallel processing. You must also prepare any existing application that was designed for single-instance Oracle, to be ready for multi-instance.
Besides migrating your existing database from single instance Oracle to multi-instance Oracle, you must also migrate any existing application which was designed for single-instance Oracle. Preparing an application for use with a multi-instance database may require application partitioning and physical schema changes.
See Also: "Application Analysis" ![[*]](jump.gif)
for a full discussion of how to do this.
Administrative Issues
Note the following ramifications of conversion:
See Also: "Backing Up the Database" .
Converting the Database from Single- to Multi-instance
The following procedure explains how to migrate an existing database from single instance Oracle to multi-instance Oracle. Remember that you must also migrate the application from single-instance to multi-instance.
1. Make sure that all necessary files are shared between the nodes.
Attention: NFS cannot be used to share files for Oracle7 Parallel Server. NFS does not provide adequate availability: if the node goes down, NFS goes down and the files cannot be reached. Likewise, NFS does not provide adequate consistency: a write may be cached and not written to disk immediately.
2. Check MAXINSTANCES on the single instance.
SQL> SELECT THREAD#, STATUS, ENABLED FROM V$THREAD;
Lines like the following will be returned:
THREAD# STATUS ENABLED
1 OPEN PUBLIC
1 row selected.
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
The trace file may look like this:
Dump file /mf1/qjones/qj1/rdbms/log/ora_20016.trc
Oracle7 Server Release 7.3.2.0.0
With the distributed, replication, parallel query and Parallel Server options
PL/SQL Release 2.2.2.0.0
ORACLE_HOME = /mf1/qjones/qj1
ORACLE_SID = mf1qj1
Oracle process number: 19 Unix process id: 20016
System name: mf1seq
Node name: mf1seq
Release: 3.2.0
Version: V2.1.1
Machine: i386
Wed Feb 22 14:30:22 1995
Wed Feb 22 14:30:23 1995
*** SESSION ID:(18.1)
# The following commands will create a new control file and
# use it to open the database.
# No data other than log history will be lost. Additional logs
# may be required for media recovery of offline data files.
# Use this only if the current version of all online logs are
# available.
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "TPCC" NORESETLOGS
NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 62
MAXINSTANCES 1
MAXLOGHISTORY 100
LOGFILE
GROUP 1 `/dev/rvol/v-qj80W-log11' SIZE 200M,
GROUP 2 `/dev/rvol/v-qj80W-log12' SIZE 200M
DATAFILE
`/dev/rvol/v-qj80W-sys',
`/dev/rvol/v-qj80W-temp',
`/dev/rvol/v-qj80W-cust1',
.
.
.
;
# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or
# immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;
3. Recreate the control file with a larger MAXINSTANCES value.
The resulting control file is a script that will recover and reopen your database if necessary.
Before you run the SQL file, make sure that the current control file(s) are moved to the backup directory.
STARTUP NOMOUNT PFILE=$HOME/perf/tkvc/admin/tkvcrun.ora
CREATE CONTROLFILE REUSE DATABASE "TPCC" NORESETLOGS
NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 62
MAXINSTANCES 1
MAXLOGHISTORY 100
LOGFILE
GROUP 1 `/dev/rvol/v-qj80W-log11' SIZE 200M,
GROUP 2 `/dev/rvol/v-qj80W-log12' SIZE 200M
DATAFILE
`/dev/rvol/v-qj80W-sys',
`/dev/rvol/v-qj80W-temp',
`/dev/rvol/v-qj80W-cust1',
.
.
.
;
# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or
# immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;
Each instance will have private initialization parameters, but some of the parameters need to have the same value on each instance. There are two alternative ways of administering this.
Alteratively, you can make multiple copies of the parameter file and place one on the private disk of each node that participates in the Oracle Parallel Server. In this case you would need to update all of the parameter files each time you make a generic change.
6. Edit the following parameters in the current initialization parameter file:
7. Make sure that the following common initialization parameters have the same values for all instances:
MAX_COMMIT_PROPAGATION_DELAY
$ svrmgrl
Note: Corruption may occur if one node opens the database in shared mode and another node opens it in exclusive mode.
10. Perform a shutdown normal of the database.
11. Back up the control files using operating system commands.
12. Remove the control files.
13. Run the new script you have built, which will recreate the old control files with new data--larger structures for some of the database objects.
14. Start up the first instance.
15. Add the second instance in shared mode, using the standard procedure described . (Note that the second instance will only succeed if the first instance is in shared mode.) Add redo log files, rollback segments, and so on.
16. Modify your application to make it Oracle Parallel Server ready.
17. Tune the GC_* parameters for optimal performance.
Troubleshooting the Conversion
This section explains how to resolve common errors:
Database Recovery After Conversion
If you should lose your database and Oracle7 files after converting from single-instance Oracle to OPS, you would have to restore your cold backup and then apply all changes from the redo logs. In this case your old control file would be used, as though you had never done the conversion. You would have to recreate the new control file, if you migrate to OPS.
Loss of Rollback Segment Tablespace
The following problem may occur if a user has created tablespaces for private rollback segments, and allocated them to specific instances at startup. It may also occur if files that contain rollback segments are lost.
If you lose one rollback segment tablespace or file containing rollback segments due to media failure, all of the instances will fail. To recover, you must shut down all instances. All the other rollback segments must remain offline so that you can bring the one you want to recover off line.
Inadvisable NFS Mounting of Parameter File or Control File
It is not advisable to access a common parameter file or control file over NFS. If the NFS disk were to go down, no other instance could start.
