7
Migrating a Release 1.x Repository to a Release 2.2 Repository

The Oracle Enterprise Manager Migration Assistant supports migrating data for both Oracle Enterprise Manager and the Oracle Enterprise Manager Management Packs.

This chapter describes methods for migrating multiple Release 1.x repository schemas into an existing single "shared" Release 2.2 repository schema.

Note:
Migration requires that you first create a Release 2.2 repository using the Enterprise Manager Configuration Assistant. Migration is performed from a Release 1.x repository into an already existing Release 2.2 repository.

An Oracle Enterprise Manager Release 1.x repository schema is not the same as an Oracle Enterprise Manager "shared" Release 2.2 repository schema. In Enterprise Manager Release 1.x, each administrator had a separate repository schema which contained the current view of the network and user-specific information. In Enterprise Manager Release 2.2, administrators have accounts within a single shared repository schema, and all individual preferences are stored in the administrator's account.

A Release 2.2 repository may not coexist with a Release 1.x repository in the same schema. A Release 2.2 repository and a Release 1.x repository may reside in the same database, but in a different schema.

Note:
If you do not have a Release 1 repository, skip this chapter.

The Migration Assistant supports the migration of the following information into an existing Release 2.2 repository:

discovery information
preferred credentials
job information
event information
groups

Note:
The Migration Assistant only runs on Windows NT, but it can migrate repository data from any Release 1.x repository to Release 2.2 regardless of the source and destination repository database platforms.

Important Notes

Note:
Before you start migration, you must back up the database and the Release 1.x repository to ensure that the current Release 1.x Oracle Enterprise Manager environment and Release 2.2 environment can be recovered in the event of an unexpected failure.

Note:
If you perform any work with Release 2.2 after you have fully migrated your Release 1.x repository to Release 2.2, you cannot go back to using that repository with Release 1.x. Rolling back to Release 1.x due to problems during repository migration to Release 2.2 is supported only if you perform the complete set of pre-migration steps and you do not begin work in the Release 2.2 environment.

Phases of Migration

The phases for migrating a Release 1.x repository are listed below:

Preparing for Repository Migration
Migrating the Repository Using the Migration Assistant
Deleting and Deregistering All Active Jobs and Events from the Release 1.x Console. If you do not delete and deregister active jobs and events from the Release 1.x Console, there could be duplicate jobs running at the Intelligent Agent. Events will fail to register due to "not unique" errors.
Confirming a Successful Migration

How the Differences Between Release 1.x and Release 2.2 Impact Migration

The repository migration operation changes the existing Release 1.x repository in several ways.

Refer to Release 1.x Objects Reference on page 7-24 for a comprehensive list of the Release 1.x objects and whether or not they can be migrated to Release 2.2.

Repository

The Oracle Enterprise Manager Migration Assistant migrates Release 1.6.5 repositories to Release 2.2. If the Oracle Enterprise Manager Migration Assistant is run against a release earlier than 1.6.5, that repository is first upgraded to 1.6.5 in place, and then the upgraded repository is migrated to 2.2. Oracle Enterprise Manager Release 1.2 is the earliest version supported for in-place upgrades to version Release 1.6.5. If the target repository version is less than 1.6.5, then after the migration it is no longer functional with Oracle Enterprise Manager Release 1.x. Before beginning the migration of any repository, first back up the schema and/or tablespace.

Preferred Credentials

Username, passwords, and roles are migrated. When migrating multiple Release 1.x repositories to a single Release 2.2 repository with one administrator, the first preferred credentials migrated for a service which existed in more than one Release 1.x repository will be the preferred credentials from the first Release 1.x repository migrated.

Groups

In Release 1.x, jobs and events can be registered against a group appear as a single job or event on the Console. In Release 2.2, when a job or event is registered against a group, a separate job/event object appears in the Console for each service on which the job/event is registered. When migrating a job/event registered against a group in Release 1.x to Release 2.2, a separate job or event object will appear in the Release 2.2 Console for each service within that Group on which the job/event is registered.

Jobs

Only active jobs that are not "fixit" jobs and active jobs that fall within the Release 2.2 frequency limitations will be automatically submitted to the Oracle Enterprise Manager Job System.
If a job named NAME was migrated to a target database where a job was already named NAME, it would be renamed to NAME(1) during migration. If there already was a NAME(1), it would be renamed to NAME(2), and so on.

Backup Jobs

If a backup job is running in Release 1.x and you migrate the data, the job appears as a tcl job in Release 2.2. Note: Backup jobs in the job library will not be migrated. Backup Manager Jobs differ significantly from Backup Tablespace Jobs in the Oracle Enterprise Manager Console.

Fixit Jobs

Release 1.x fixit jobs are migrated to the Release 2.2 job library, but are not automatically submitted. The Release 2.2 fixit jobs must be resubmitted from the Release 2.2 job library manually after migration. A Release 1.x event associated with a Release 1.x fixit job is separated and placed in the Release 2.2 event library and Release 2.2 job library respectively (not submitted). After migration, you must edit the Release 2.2 event in the Release 2.2 event library and reassociate it with the "V2 manually resubmitted" fixit job.

Events

Only registered events that are not associated with "fixit" jobs and events that fall within the Release 2.2 frequency limitations will be automatically submitted.
If an event named NAME was migrated to a target database where an event was already named NAME, it would be renamed to NAME(1) during migration. If there already was a NAME(1), it would be renamed to NAME(2), and so on.
The Event "Destination Type" must be the same in Release 2.2 to associate a fixit job with an event. For example, if you created a Release 1.x event with a "Service Type" "Database" and you had associated it with a Release 1.x Fixit Job such as a "Broadcast Message" of "Service Type" "Node". The Release 1.x event and Release 1.x fixit job with different "Service Types" can be associated and registered together. In Release 2.2 the "Destination Type" must be the same as the fixit job "Destination Type" to associate and register them together.

If you migrate an event and a fixit job like the above example, you must perform a "Create Like..." on the Release 1.x fixit job and change the Release 2.2 "Destination Type" of this job to match the "Destination Type" of the Release 2.2 event.

Event Sets
With the Release 1.x architecture, an "event set" is a collection of individual events which were registered to a discovered service. In the Release 2.2 architecture, an "event" is the collection of individual tests. The Release 2.2 "event" is similar to the Release 1.x "event set." In Release 2.2, the individual Release 1.x "events" are now called "tests." Each "test" still has the same possibilities and settings as the Release 1.x Events, and an Event can be defined in the same way as a Release 1.x Event Set. When migrating Release 1.x Event Sets, each Release 1.x event within the event set is migrated to Release 2.2 as a separate event.
For Release 2.2 Events, frequency, frequency units, and fix it jobs are assigned at the "Event" (or top) level. These items were assigned at the Release 1.x "Event" (or low) level. If these items are not the same for all Events in a Release 1.x Event Set, each Event in the Release 1.x Event Set will be migrated to a separate Release 2.2 Event. If these items are the same for all Events in a Release 1.x Event Set, the entire Release 1.x Event Set will be migrated to a single Release 2.2 Event.

Frequency

Frequency options for jobs and events in Release 2.2 differ from those in Release 1.x. Jobs or events that have a frequency that is supported in Release 1.x but not supported in Release 2.2 must be submitted or scheduled again in the Release 2.2 environment. For example: Release 2.2 events support polling intervals of 23:59 hours or less. Release 1.x supports polling intervals greater than 23:59 hours.

Performance Manager/Capacity Planner

Any number of Release 1.x Performance Manager/Capacity Planner repositories can be migrated to the Release 2.2 repository, but each must be associated with its own unique Release 2.2 administrator.

Change Management Pack

CAUTION: If you are migrating a Change Manager Release 1.5.5 repository, the migration process will first upgrade it to Release 1.6.5 before migrating it. This upgrade cannot be reversed, and you will be unable to use Change Manager Release 1.5.5 with this repository. You may therefore want to back up the Release 1.5.5 repository, and restore it after the migration, in order to continue using it with Change Manager Release 1.5.5.
Each Oracle Change Management Pack Release 1.x repository that you migrate must be migrated to a Release 2.2 repository that contains no change plans or baselines for any of the administrators. If any change plans or baselines exist for any administrator, you must delete the plans or baselines before starting the Change Management Pack Release 1.x repository migration. If you do not, the Change Management Pack migration fails. In this situation, the sysman\temp\vobmgr.log file contains messages that identify which administrators in the Release 2.2 repository have plans or baselines that must be deleted. Use Plan Manager to delete change plans and DB Capture to delete baselines.

Expert

The Oracle Expert Release 1.x repository tables are migrated to a Release 2.2 repository using an Oracle Expert tuning session export/import methodology. All tuning sessions under all databases in the Release 1.x repository are exported into .xdl files (one per database) and then imported into the Release 2.2 repository under the selected Oracle Enterprise Manager user.

Paging Services

Schedule information for a Release 1.x user will not be migrated to a Release 2.2 Administrator. Each user must define a new paging schedule in the Release 2.2 environment.
Paging configuration information will not be migrated to Release 2.2. Each user must define new paging confirmation information in the Release 2.2 environment.

Email Services
Schedule information for a Release 1.x user will not be migrated to a Release 2.2 Administrator. Each user must define a new email schedule in the Release 2.2 environment.
Email configuration information will not be migrated to Release 2.2. Each user must define new email confirmation information in the Release 2.2 environment.

Manually Discovered Nodes and Manually Added Services

Manually discovered nodes and manually added services will not be migrated.

Preparing for Repository Migration

To prepare for a successful migration, you must complete the following procedures:

Install Oracle Enterprise Manager Release 2.2. Refer to the installation guide provided with the database release for detailed information.
Create New Release 2.2 Administrators
Refresh All Services in the Release 1.x Console
Shut Down the Release 1.x Console and the Release 2.2 Management Server
Check the Information Currently in the Release 1.x Repository
Back Up the Existing Release 1.x Repository

Create New Release 2.2 Administrators

Using the Migration Assistant, you can migrate a single Release 1.x repository to a single Release 2.2 repository or migrate multiple Release 1.x repositories to a single Release 2.2 repository.

For both cases, you must first create the new administrators which will have Release 1.x repository information migrated to their Release 2.2 account.

Each Enterprise Manager administrator is a separate user in the repository database account.

Note:
If you do not create new Release 2.2 administrators, all objects migrated are migrated to the SYSMAN account. The SYSMAN account is the default super administrator account provided when you install Oracle Enterprise Manager Release 2.2.

To create new administrators, follow the steps below:

Start the Management Server.

Refer to Chapter 3, "Controlling the Management Server" for detailed information on starting the Management Server.
Log into the Oracle Enterprise Manager Console Release 2.2 using the SYSMAN account. Refer to Chapter 6, "Setting Up the Console" for detailed information on starting the Enterprise Manager Console.
Select Manage Administrators from the Console's System menu. The Manager Administrator Accounts dialog appears.
Click the Add button in the Manage Administrator Accounts dialog. The Create Administrator Account dialog appears.
Enter a unique username and password for the Enterprise Manager administrator and check the access available to the administrator:

For more information on managing Enterprise Manager Administrators, refer to the the Oracle Enterprise Manager Administrator's Guide.

Refresh All Services in the Release 1.x Console

Before migration, you must make sure that all services that need to migrate have been successfully refreshed by the Release 1.x Console.

Any service that has not been successfully refreshed will not migrate.

Shut Down the Release 1.x Console and the Release 2.2 Management Server

Shut down the Release 1.x Console and the Management Server, if running. The remote Intelligent Agents are left running and existing queue files are left intact.

Check the Information Currently in the Release 1.x Repository

To ensure that no information is lost during migration, check the information currently in the Release 1.x repository. Later, you will use this information as a guide to verify whether the information is present after the migration to Release 2.2.

In the V.1x repository, check for the following information:

For discovery information, count the number of discovered hosts and services in the Release 1.x environment
View the credential information for at least one node
For job information, relevant information to note includes the following:
- number of jobs
- type of job
- job state
- job history information
For event information, note relevant information such as the following:
- number of event groups
- number of events in each group
- nodes where each group is registered
- current state of the event

Back Up the Existing Release 1.x Repository

The Migration Assistant does not support automatic recovery when an unexpected error occurs during the migration. To ensure that the current Release 1.x Oracle Enterprise Manager environment and Release 2.2 environment can be recovered in the event of an unexpected failure, you should backup both the Release 1.x repository and the Release 2.2 repository.

Note:
A repository created under the SYS user cannot be exported.

To backup the repository, you may use Enterprise Manager's Export wizard or the EXPORT utility, a base utility shipped with the Oracle database server. For information about using Data Management wizards, refer to the Oracle Enterprise Manager Online Help.

The following example is from an NT environment running an 8.0 server.

exp80 user/password@service owner=oemv1schema file=oemv1.dmp

where USER is the username for the Oracle Enterprise Manager repository to be migrated and PASSWORD is the password for the user.

In this example, the saved repository is written to oemv1.dmp.

A message appears at the end of the export, telling you whether the export completed successfully:

Export terminated successfully without warnings.

For detailed information about the Export utility, refer to Oracle8i Release 2 (8.1.6) Utilities.

Migrating the Repository Using the Migration Assistant

Follow the instructions for each database in the Release 1.x Oracle Enterprise Manager environment you want to migrate.

Start the Enterprise Manager Migration Assistant from the Windows NT Start Menu.

Step 1 "Introduction"

After launching the Migration Assistant, the "Introduction" page appears, providing important information about the purpose of the Migration Assistant and any preconditions that are required for the migration to be successful.

Figure 7-1 Introduction

Text description of the illustration ma_p1.gif

Read the introduction; then, press Next to continue.

If you have one or more system management packs installed, proceed to Step 2 "Component Selection" on page 7-14.

If you do not have any system management packs installed, proceed to Step 3 "Source Repository Login" on page 7-15.

Step 2 "Component Selection"

Note:
The Component Selection page only appears if you have one or more system management packs installed.

Choose the repository components that you want to migrate.

Only installed components are available for selection. If a valid target repository does not exist for the component, one will be created.

Figure 7-2 Component Selection
Text description of the illustration ma_p2.gif

After you have made your selection, press the Next button to continue.

Step 3 "Source Repository Login"

Figure 7-3 Source Repository Login
Text description of the illustration ma_p3.gif

Username and Password: You must provide a valid username for the database where the Release 1.x repository is located.

Service: Use the standard SQL*Net V2 or Net8 syntax. The service name is the name of the database as it appears in the tnsnames.ora file.

Connect As: Connect as "Normal."

Press Next to continue.

If the information supplied is valid and a valid Release 1.x repository is present, proceed to Step 4 "Target Repository Login" on page 7-16.

Step 4 "Target Repository Login"

Provide the username, the password, and the service name for the new Release 2.2 repository.

Figure 7-4 Target Repository Login
Text description of the illustration ma_p4.gif

Username and Password: The Oracle Enterprise Manager username must be the same as the username under which the Release 2.2 repository is created. In other words, these are the repository schema owner's credentials. The Oracle Enterprise Manager Release 2.2 repository is an Oracle database schema. The user name and password is not the Oracle Enterprise Manager user logon.

Service: Use the standard SQL*Net V2 or Net8 syntax. The service name is the name of the database as it appears in the tnsnames.ora file.

Press Next to continue.

If you have provided a valid repository name, password, and service for a valid Release 2.2 repository, proceed to Step 5 "Administrator Data" on page 7-18. The Oracle Enterprise Manager Migration Assistant also informs you through a dialog if the information to be migrated already exists in the Release 2.2 repository and if the format of the information is different from the format of the Release 1.x information and how this information has been converted.

Step 5 "Administrator Data"

Specify the Release 2.2 administrator where the information will be migrated.

Note:
If you have not created additional Release 2.2 administrator accounts, all object migrated will be migrated to the SYSMAN administrator account.

Figure 7-5 Version 2.2 Administrator Data
Text description of the illustration ma_p5.gif

Click Finish to initiate the migration process or click Back to return to previous pages to change the information.

Work in Progress

A Work in Progress window appears, showing your progress. All information in the Work in Progress window is logged into the vobmgr.log file, which is located in the %oracle_home%\sysman\temp directory.

Note:
If you are migrating a Release 1.x repository with the Change Management Pack installed but have not yet used a Change Management Pack application, the Change Management objects will automatically be created in the new Release 2.2 repository.

Deleting and Deregistering All Active Jobs and Events from the Release 1.x Console

The repository migration from Release 1.x into the Release 2.2 environment must be coordinated. Part of the migration process is to delete and deregister all active Release 1.x jobs and events by hand.

Job and event information defined in the Release 1.x repository is copied to the Release 2.2 repository.

After performing the repository migration, follow the steps outlined below:

Start the Release 1.x Console, connecting to the Release 1.x repository that was just migrated.
Delete/deregister all active jobs and events manually. If you do not delete and deregister active jobs and events, there could be duplicate jobs running at the Intelligent Agent. Events will fail to register due to "not unique" errors.

Note:
If you migrate information and do not start the Release 1.x Console and remove jobs and events before starting the Management Server; then, the initial start will attempt the registration of events and submission of jobs. Jobs will register, but events may fail as the event is already registered with the Intelligent Agent from the Release 1.x Console (Intelligent Agent's restriction on uniqueness of events).
The failure will be presented at the Console. You can de-register the Release 1.x event and attempt the re-registration via Create Like... from the failed event registration on the Release 2.2 Console.

Shut down the Release 1.x Console(s).
Start the Management Server.

Note:
You must repeat the same steps to migrate each of the Release 1.x repositories into the single Release 2.2 repository.

Confirming a Successful Migration

After the Migration Assistant has moved the Release 1.x repository information into the specified Release 2.2 administrator, login to the Release 2.2 Console as that administrator and confirm the migration.

You must ensure that all information is present after repository migration by checking that the discovery, preferred credentials, job and event information has migrated successfully.

For discovery information, check that the hosts and services are represented after migration via the Console navigator.

Note:
The Migration Assistant does not migrate any manually discovered targets.

Credential information for at least one node should be viewed by using the Release 2.2 Console navigator to access the database using the migrated credentials.

Note:
If the Release 2.2 Console is unable to match the migrated service name with the service name stored in the credentials table that the Release 1.x Console used, you must reenter the preferred credentials through the Release 2.2 Console after migration for the affected service.

For job information, relevant information to check include the number of jobs, the type of job, and the job state, and relevant job history information. Certain Release 1.x jobs contain tasks which do not migrate into Release 2.2. These need to be taken into account as well. Refer to Release 1.x Objects Reference on page 7-24 for job tasks that do not migrate.
For event information, relevant information to note includes the number of events, the number of tests in each event, the nodes where each group is registered, and the current state of the event. Refer to Release 1.x Objects Reference on page 7-24 for event tests that do not migrate.
For the number of Performance Manager recordings and user-defined charts which were successfully migrated, check the migration log file, sysman\temp\vobmgr.log.
For information about the Oracle Expert migration process, check the sysman\temp\vobmgr.log file and the more detailed sysman\temp\xpomigr.log file.
For Change Management you need to count the number of baselines and change plans in PlanMan and Capture in Release 1.x and compare the number to the number migrated in Release 2.2.

Backing out of a Migration

In the event of an unexpected problem during the migration, you may need to restore the Oracle Enterprise Manager environment to its previous state. To restore the Oracle Enterprise Manager environment:

Drop the old Release 1.x repository user using DBA Studio's Security Management. Refer to the Oracle Enterprise Manager Online Help for detail information about Security Management.
Import the saved Release 1.x repository user using Import wizard or the IMPORT utility, a base utility shipped with the Oracle database server. The user is recreated when you import. For information about using Import wizard, refer to the Oracle Enterprise Manager Online Help. The following example uses the IMPORT utility.
```
imp user/password@service file=oemv1.dmp
```

Importing the schema will "recreate" the Release 1.x repository as it was before migration.

Note:
Jobs and events must be reregistered if they have been deregistered.

For detailed information about the Import utility, refer to Oracle8i Utilities.

Release 1.x Objects Reference

Refer to the sections below for a comprehensive list of the Release 1.x objects and whether or not they can be migrated to Release 2.2.

Release 1.x Objects Which Will Migrate to Release 2.2

The following Release 1.x objects can be migrated to Release 2.2:

Preferred Credentials

Services

Databases, Nodes and Listeners are migrated if the status of the last discovery/refresh of these services was successful.

Groups: In Release 1.x, jobs and events are registered against groups as a single object. If a job or event is registered to a group in Release 1.x; then, the job or event is migrated to Release 2.2 by creating a separate job or event for each service on which the job or event is registered.

The job or event is not migrated to a group since groups are not migrated as a logical entity. No group will exist on the Release 2.2 side. All of the Release 1.x group members will migrate individually to Release 2.2. The group will need to be recreated in Release 2.2, and the migrated members must be added again.

Jobs

Run DBA Script

Startup Database

Run TCL

Run SQL * Plus

Broadcast Message

Shutdown Listener

Shutdown Database

Run OS Command

Startup Listener

Fixit Jobs

All Schedule Information

Override Preferred Credentials

Job History

Dependent Jobs

Job Library

Active Jobs

Events

Alert

Probe

UpDown (Database)

Buffer Cache

Data Dictionary Cache

Disk I/O

Library Cache

Net I/O

SysStat Table

SysStat Table Delta

Datafile Limit

Lock Limit

Process Limit

Session Limit

User Limit

Archive Full

Chunk Small

Dump Full

Maximum Extents

User Blocks

Continued (chained) Row

UpDown (listener/sqlnet)

UpDown (node)

CPU Paging

CPU Utilization

Disk Full

Swap Full

Archiver Hung

Broken Jobs

Data Block Corruption

Deferred Transactions

Error Transactions

Failed Jobs

Session Terminated

Unscheduled Jobs

Free Buffer

In Memory Sorts

Index Rebuild

Redo Log Allocation

Roll Back Contention

Alert File Large

Fast Segment Growth

Multiple Extents

Snapshot Log Full

Tablespace Full

User Audit

Data Gatherer Alert

Data Gatherer UpDown

Others

Event Set Library

Registrations

Third Party Events

Fixit Jobs Associated with Triggered Events

Frequency

Pack Repositories

Release 1.x Objects Which Need to be Re-created

The following objects need to be re-created:

Jobs

Backup Tablespace from Oracle Enterprise Manager Jobs

Export

Import

Load

Others

SNMP Traps

Paging Services

Email Services

Administrator Lists

manually added services

manually discovered targets

Release 1.x Objects Which No Longer Exist

Release 1.x objects which no longer exist in Release 2.2 are listed below:

Jobs

Deinstall Products

Delete Package

Distribute Package

Install Package

Events

Rdb Database Events

Rdb Services Events

Event History

Outstanding Events

Others

Maps

Run DBA Script	Startup Database	Run TCL
Run SQL * Plus	Broadcast Message	Shutdown Listener
Shutdown Database	Run OS Command	Startup Listener

All Schedule Information	Override Preferred Credentials	Job History
Dependent Jobs	Job Library	Active Jobs

Alert	Probe	UpDown (Database)	Buffer Cache
Data Dictionary Cache	Disk I/O	Library Cache	Net I/O
SysStat Table	SysStat Table Delta	Datafile Limit	Lock Limit
Process Limit	Session Limit	User Limit	Archive Full
Chunk Small	Dump Full	Maximum Extents	User Blocks
Continued (chained) Row	UpDown (listener/sqlnet)	UpDown (node)	CPU Paging
CPU Utilization	Disk Full	Swap Full	Archiver Hung
Broken Jobs	Data Block Corruption	Deferred Transactions	Error Transactions
Failed Jobs	Session Terminated	Unscheduled Jobs	Free Buffer
In Memory Sorts	Index Rebuild	Redo Log Allocation	Roll Back Contention
Alert File Large	Fast Segment Growth	Multiple Extents	Snapshot Log Full
Tablespace Full	User Audit	Data Gatherer Alert	Data Gatherer UpDown

Event Set Library	Registrations	Third Party Events
Fixit Jobs Associated with Triggered Events	Frequency	Pack Repositories

Backup Tablespace from Oracle Enterprise Manager Jobs	Export
Import	Load

SNMP Traps	Paging Services	Email Services
Administrator Lists	manually added services	manually discovered targets

Deinstall Products	Delete Package
Distribute Package	Install Package

Rdb Database Events	Rdb Services Events
Event History	Outstanding Events

7 Migrating a Release 1.x Repository to a Release 2.2 Repository