| Oracle® Database System Administration Guide 10g Release 2 (10.2) for IBM z/OS on System z Part Number B25398-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Database System Administration Guide 10g Release 2 (10.2) for IBM z/OS on System z Part Number B25398-03 |
|
|
PDF · Mobi · ePub |
This chapter provides z/OS-specific upgrade information and is intended to be used in conjunction with Oracle Database Upgrade Guide.
The following topics are included:
In order to upgrade your Oracle Database for z/OS to 10g release 2, the z/OS system must be V1.4 or later. This requirement also applies to client applications, including tools, utilities, Access Managers and customer applications.
Direct upgrade is supported on z/OS for OSDI-based Oracle8i release 8.1.7.4 or Oracle9i release 2. Depending on your current release, you may need to upgrade to an interim level prior to upgrading to 10g release 2. If upgrading from Oracle8i release 8.1.7.4, review the the section "OSDI Changes in Oracle9i Release 2".
The information in this section supplements Chapter 2, "Preparing to Upgrade" in the Oracle Database Upgrade Guide.
The Database Upgrade Assistant is not supported on z/OS. A manual upgrade is required for the upgrade method. Refer to the section "Upgrade the Database Manually" in Chapter 3 of the Oracle Database Upgrade Guide.
The information in this section supplements Chapter 3, "Upgrading a Database to the New Oracle Database 10g Release" in the Oracle Database Upgrade Guide.
For instructions on how to install Oracle Database for z/OS 10g release 2, refer to the Oracle Database Installation Guide for IBM z/OS (OS/390).
Use the Pre-Upgrade Information tool as described in the section "Analyze the Database to be Upgraded" in Chapter 3 of the Oracle Database Upgrade Guide.
Run the JCL in INSTLIB(UPGU102I) which calls the utlu102i.sql script.
This section describes the z/OS-specific backup tasks to perform before upgrading you database.
To make sure your Oracle instance is shut down cleanly, perform a SHUTDOWN NORMAL (or IMMEDIATE) and allow it to complete. If it cannot complete because user sessions remain connected, perform a SHUTDOWN ABORT or forcibly terminate the OSDI service. Then, perform a fresh STARTUP followed by SHUTDOWN NORMAL. It is important for SHUTDOWN NORMAL to complete, ensuring that no outstanding redo data remains in the database. Finally, stop the associated service with an OSDI STOP command or a z/OS STOP (P) command to cause its address space(s) to terminate.
This step is recommended, though not mandatory, if you are upgrading from Oracle8i release 8.1.7.4 and Oracle9i release 2. It provides an extra measure of assurance that no data can be lost in the upgrade process.
Back up the entire database, including control files, online log files, and data files. This can be done with a fast physical data mover such as IBM's DF/DSS. In the following batch JCL example, DF/DSS is used to back up an Oracle7 database, where all of the Oracle7 database files begin with"ORACLE.ORA1":
//BACKUP EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DUMPDS DD DSN=ORACLE.ORA1BK.FULL, // DISP=(NEW,CATLG,DELETE,) // UNIT=3480, // VOL=(,,,99,SER=(vol001,vol002,vol003....)), // LABEL=(1,SL,EXPDT=98000) //SYSIN DD * DUMP DATASET(INCLUDE(ORACLE.ORA1.**) ) - OUTDD(DUMPDS) /*
This section contains information about how to upgrade the database.
In this step, you perform a STARTUP of the new release of Oracle Database. If the associated OSDI database service is still active, stop it with an OSDI STOP command or a z/OS STOP (P) command. After the service terminates, you must modify the service to use the new release code. There are two ways to do this, as follows:
Modify the existing JCL procedure for the service to specify the new release library in STEPLIB.
Create a new JCL procedure for the service using a different name from that of the prior release, and use the OSDI ALTER SERVICE command to switch the service to the new procedure. If you choose this option, make sure that the new procedure will be assigned the correct z/OS userid when started. If in doubt, talk to your system security administrator.
It also is possible to define a new OSDI service (specifying a new JCL procedure) and use this to start up the new release. However, the new service cannot have the same SID as the prior release (assuming both are on the same z/OS system) because SIDs must be unique. In most cases you will want the new release to run using the same SID as the prior release.
Make sure that your init.ora parameter file for the new release is ready. Refer to the section "Oracle Initialization Parameter Considerations" in Chapter 3, "Configuring a Database Service and Creating a New Database" for new or changed parameters. Also, evaluate the information obtained from the Pre-Upgrade Information tool and refer to the section "Upgrade the Database Manually" in Chapter 3 of the Oracle Database Upgrade Guide.
First, start the OSDI database service with an OSDI START command. Make sure the service initializes successfully, signified by message MIR0002I in the system log.
Next, perform an Oracle STARTUP using SQL*Plus from the new release. You can do this from TSO, from a UNIX System Services shell, or by using a batch job. The examples provided here use batch jobs and identify the target instance with an ORA@sid DD statement. This DD supplies the OSDI SID. However you choose to run SQL*Plus, if you have configured OSDI security features the associated z/OS userid must have the required authorizations: it must be authorized to bind to the database service and it must be able to CONNECT using AS SYSDBA. The following is a batch JCL example:
//PLUS EXEC PGM=SQLPLUS,REGION=0M,PARM='/nolog' //STEPLIB DD DISP=SHR,DSN=ORACLE.V10G.CMDLOAD //ORA$LIB DD DISP=SHR,DSN=ORACLE.V10G.MESG //INITORA DD DISP=SHR,DSN=ORACLE.ORA1.PARMLIB(INITORA1) //ORA@ORA1 DD DUMMY <-- OSDI SID is 'ORA1' //SYSIN DD * CONNECT / AS SYSDBA STARTUP PFILE='//DD:INITORA' UPGRADE /*
Refer to the section "Upgrade the Database Manually" in Chapter 3 of the Oracle Database Upgrade Guide, for common errors that may occur when attempting to start up the new Oracle Database release.
Refer to the section "Upgrade the Database Manually" in Chapter 3 of the Oracle Database Upgrade Guide, for the details on the CREATE TABLESPACE command.
The following batch JCL example creates a SYSAUX tablespace:
//PLUS EXEC PGM=SQLPLUS,REGION=0M,PARM='/nolog' //STEPLIB DD DISP=SHR,DSN=ORACLE.V10G.CMDLOAD //ORA$LIB DD DISP=SHR,DSN=ORACLE.V10G.MESG //INITORA DD DISP=SHR,DSN=ORACLE.ORA1.PARMLIB(INITORA1) //ORA@ORA1 DD DUMMY <-- OSDI SID is 'ORA1' //SYSIN DD * CONNECT / AS SYSDBA CREATE TABLESPACE ... /*
In this step, you run a SQL script to upgrade the Oracle dictionary structures to the new release.
Run the JCL in INSTLIB(UPGCAT) which calls the catupgrd.sql script.
Examine the SQL*Plus output from these scripts and the Oracle instance alert log for significant error indications. Certain DROP statements in the scripts may produce "object not found" errors which are not considered significant. Other errors, particularly ORA-0060x (internal) errors, must be resolved before proceeding.
The Post-Upgrade Status tool displays the status of the database components in the upgraded database.
Run the JCL in INSTLIB(UPGU102S) which calls the utlu102s.sql script.
The following batch JCL example runs the utlu102s.sql script:
//PLUS EXEC PGM=SQLPLUS,REGION=0M,PARM='/nolog'
//STEPLIB DD DISP=SHR,DSN=ORACLE.V10g.CMDLOAD
//ORA$LIB DD DISP=SHR,DSN=ORACLE.V10g.MESG
//SQL DD DISP=SHR,DSN=ORACLE.V10g.SQL
//ORA@ORA1 DD DUMMY <-- OSDI SID is 'ORA1'
//ORA$FNA DD *
FSA (FTYPE(SQL) FNAME('//DD:SQL(+)'))
FSA (FTYPE(PLB) FNAME('//DD:SQL(+)'))
/*
//SYSIN DD *
CONNECT / AS SYSDBA
@utlu102s.sql TEXT
/*
This step is required to perform internal housekeeping tasks. At the end of the STARTUP process, your database is migrated or upgraded and is usable. However, you should perform a STARTUP without RESTRICT, to enable normal client access, as shown in the following batch JCL example:
//PLUS EXEC PGM=SQLPLUS,REGION=0M,PARM='/nolog' //STEPLIB DD DISP=SHR,DSN=ORACLE.V10G.CMDLOAD //ORA$LIB DD DISP=SHR,DSN=ORACLE.V10G.MESG //INITORA DD DISP=SHR,DSN=ORACLE.ORA1.PARMLIB(INITORA1) //ORA@ORA1 DD DUMMY <-- OSDI SID is 'ORA1' //SYSIN DD * CONNECT / AS SYSDBA SHUTDOWN IMMEDIATE STARTUP PFILE='//DD:INITORA' /*
Some stored procedures in the database will have been invalidated during migration or upgrade due to changes in underlying database objects. Although these will recompile dynamically as needed, Oracle recommends forcing the recompiles. This involves running a supplied script to verifiy that all expected packages and classes are valid.
Refer to the section "Upgrade the Database Manually" in Chapter 3 of the Oracle Database Upgrade Guide for more information.
Run the JCL in INSTLIB(UPGUTLRP) which calls the utlurp.sql script.
If you encounter problems, refer to the section "Troubleshooting the Upgrade" in Chapter 3 of the Oracle Database Upgrade Guide.
If you encounter problems with the new Oracle Database release, you may need to fall back (return) to your prior Oracle Database release. To fall back, perform a SHUTDOWN of the newly installed release instance, if possible, and STOP the OSDI service, waiting for all service address spaces to terminate.
Refer to Chapter 7, "Downgrading a Database Back to the Previous Oracle Database Release" in the Oracle Database Upgrade Guide for information on using the backup database created prior to the upgrade, or, if you have used the COMPATIBLE database parameter, the sequence of scripts to be used to downgrade the database.
Refer to Chapter 4, "After Upgrading the Database" in the Oracle Database Upgrade Guide for information on tasks and the asociated scripts to run after upgrading a database. The scripts can be run from TSO, from a UNIX Systems Services shell, or by using a batch job, modifying the sample SQL*Plus jobs provided in this section.
Oracle9i, R2 introduces several z/OS architectural changes described here.
Starting with Oracle9i, R2, z/OS Oracle client programs that use Oracle Net open network protocol connections directly rather than using the Oracle Net service. This affects customer-written Oracle applications running in CICS TS, TSO, and batch and Oracle tools or utilities running in TSO and batch. It also affects situations where a z/OS database instance operates as a "network client", including opening network database links and connections for the UTL_HTTP PL/SQL package. It does not affect Oracle applications, tools, or utilities running in a UNIX System Services shell environment: these programs are already using network protocol services directly.
Previously, the network protocol interaction for applications not running in a UNIX System Services shell environment was executed by the network service address space on the client's behalf. Now it is executed directly from the client's z/OS address space and TCB. This change is expected to improve performance and eliminate client operational dependence on the network service. It has the following external considerations:
OMVS dubbing. IBM's TCP/IP protocol makes use of UNIX System Services. A z/OS address space that uses IBM TCP/IP must therefore be a UNIX System Services process or be capable of being "dubbed". Dubbing occurs automatically when needed but it requires the z/OS userid associated with the address space to have a default UNIX System Services segment defined in the security subsystem (e.g. RACF). If dubbing fails, the network connection will not be opened and the application probably will fail. You must ensure that all z/OS clients that connect to remote Oracle servers can be dubbed. If in doubt, discuss this with your z/OS security administrator.
No client dependence on network service. With this change, stopping and starting the Oracle network service has no effect on z/OS client network connections. z/OS clients no longer require a TNS@xxx DD statement or other specification o identify a network service to use, and they no longer require OSDI bind authority to the network service. The network service is now involved only with inbound network operations (clients on other systems who are connecting to a z/OS database instance).
Beginning with Oracle9i, R2, all Oracle client software on z/OS, including Oracle tools, utilities, and the Oracle program interface code used by customer applications, uses IBM Language Environment (LE) for C program runtime services. LE replaces the MVS Oracle C runtime library in use since 1986. This change is primarily internal in nature but it does affect a few externals, including the syntax used to specify files and certain PARM and command line features. It also requires that LE runtime (e.g. SYS1.SCEERUN) be available in the system linklist or JOBLIB/STEPLIB when running Oracle tools, utilities, or customer-written applications.
Detailed information on this change is provided in the Oracle Database User's Guide for IBM z/OS. Since Oracle database administration involves running Oracle tools and utilities, refer to the Oracle Database User's Guide for IBM z/OS as necessary when performing administration tasks discussed in this manual.
Beginning with Oracle9i, R2, the OSDI network service is involved only in inbound network operations, that is, when remote clients connect to a z/OS Oracle instance. Outbound clients on z/OS--ones who are connecting to remote Oracle instances--interact directly with the TCP/IP protocol rather than using the network service. This is true for all Oracle9i, R2 clients: TSO, batch, UNIX System Services, Access Managers, and even the Oracle database server when it operates as a client (for example, when opening database links). You do need to run OSDI network service for inbound client support and in some cases for providing backward compatibility.
The OSDI network service is simple to configure. You must issue an OSDI DEFINE SERVICE command with TYPE(NET) to create the OSDI data structures used to manage the service. As with the database service, a JCL procedure must be installed in a system procedure library at some point before you attempt to start the service. Rather than reading a parameter data set, network service region parameters are specified directly in the PARM string of DEFINE SERVICE. Only TCP/IP is supported. A port number must be supplied; this is the port on which the service listens for inbound remote clients.
Beginning with Oracle9i, R2, the SID of the network service is irrelevant because outbound clients do not use the network service. If you have Oracle8i or Oracle9i, R1 clients making outbound network connections, the network service SID is significant since those clients must identify the network service they want to use.
As discussed earlier, OSDI database servers require no specific action or configuration to be accessible to network clients. All remote clients specify the same hostname (or IP address) and port number in the Oracle network address string or tnsnames.ora entry. The target database instance is specified using the SID parameter of CONNECT_DATA in the address string.
Oracle Access Managers for Oracle9i, R2 can access an Oracle9i, R2 local or remote database server. When accessing a remote server, Oracle Access Managers utilize the Oracle Net open network protocol with the OMVS dubbing requirement described under "Network Client Operations".
In the case where a local database server is upgraded to Oracle9iR2, earlier versions of Oracle Access Managers can access the local database if the connection in the thread table (CICS) or RTT table (IMS TM) is changed from a local definition to a remote definition using TCP/IP.
Oracle9i, R2 Access Manager for CICS TS thread definitions remain consistent with earlier versions. To access this version, customer applications must be re-linked with a new application stub (ORACSTUB). Refer to Chapter 11, "Oracle Access Manager for CICS TS" for more information.
|
 Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|