| Oracle® Enterprise Manager Concepts 10g Release 5 (10.2.0.5) Part Number B31949-10 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Concepts 10g Release 5 (10.2.0.5) Part Number B31949-10 |
|
|
PDF · Mobi · ePub |
This chapter introduces the concept of change management in the following sections:
To manage the lifecycle of enterprise applications, an organization will need to maintain multiple copies of an application database for various purposes such as development, staging, production, and testing. Each of these databases must adhere to different processes. For example, for production databases, it is essential to ensure adherence to proper production control procedures. It is vital that administrators have the tools to detect unauthorized changes, such as an index being dropped without the requisite change approvals. In such cases, monitoring changes to production databases day over day or week over week becomes vital.
Database compliance, that is, ensuring that all databases meet the gold standard configuration, is another important aspect of life cycle management. Compliance with organizational standards or best practices ensures database efficiency, maintenance, and ease of operation.
On development databases, developers make changes that the database administrator needs to consolidate and propagate to staging or test databases. The goal is to identify the changes made to development and then make the same changes to staging or test databases taking into account any other changes already in production database.
Typically, most applications will get upgraded over time. Also, most applications are customized by the business user to suit their needs. Application customizations are usually dependent on database objects or PL/SQL modules supplied by the application vendor. The application vendor supplies the upgrade scripts and the customer has very little transparency about the impact of the upgrade procedure on their customizations. When customers test upgrade databases, they can capture a baseline of the application schema before and after the upgrade. A comparison of the before and after baselines will tell the user what modules were changed by the application. This gives them a better idea about how their customizations will be impacted as a result of upgrading their application.
There are three core capabilities of Change Management that allow developers and database administrators to manage changes in database environments:
Baseline - A point in time of the definition of the database and its associated database objects.
Comparison - A complete list of differences between a baseline or a database and another baseline or a database.
Synchronization - The process of promoting changes from a database definition capture in a baseline or from a database to a target database.
For database versions 9.x and above, the user logged into the database target through Enterprise Manager must have SELECT ANY DICTIONARY privilege for capturing or comparing databases. In addition to the SELECT ANY DICTIONARY privilege, the user logging into the destination database for creating dictionary synchronization needs to be a database administrator (DBA) or must have appropriate privileges on the objects being synchronized.
A dictionary baseline contains a set of database definitions captured at a certain point in time. Baselines are stored in the Enterprise Manager repository, and are in the form of an XML document called Simple XML or SXML.
Each baseline must be assigned a unique name. A good practice to name baselines is to match it on the scope of the database objects being captured in the baseline, for example, Financial 11.5.10 or HR Benefits or PO Check Print. A baseline can have a series of versions that have been captured at different points in time. Creating multiple versions of a baseline allows you to track changes to the definitions of a set of database objects over time. You can compare two versions of the same baseline to see the changes that have occurred between them.
When creating a baseline, you also create a corresponding baseline scope specification, which describes the names and the types of database objects and schemas from which they should be captured. When you have created the baseline definition, you can then capture the first version of the baseline by submitting an Enterprise Manager job. At a later time, or at regular intervals, you can capture additional versions of the same baseline. Each baseline version records the metadata definitions as they exist at the time the version is captured.
A scope specification identifies the database objects to be captured in a baseline. (Scope specifications also identify objects to process in dictionary comparisons and synchronizations.) Once you have specified the scope of a baseline, you cannot change the scope specification. This restriction ensures that all versions of the baseline are captured using the same set of rules, which means that differences between versions result from changes in the database, not scope specification changes. To capture dictionary objects using a different scope specification, you must create a new baseline.
Baseline scope specifications take three forms.
You can specify schemas and object types to capture. For example, you can capture all Tables, Indexes and Views in schemas APPL1 and APPL2. This form of scope specification is appropriate when there is a well-defined set of schemas that contain your application objects. In addition to schema objects, you can also capture non-schema objects (such as Users, Roles and Tablespaces) and privilege grants to Users and Roles.
You can specify schemas to exclude, and object types. This form of scope specification captures objects that are contained in all schemas other than those you specify. For example, you can capture all object types in schemas other than SYSTEM and SYS. This form of scope specification is appropriate when you want to capture all database objects, with the exception of objects contained in Oracle-provided schemas. As with the first form of scope specification, you can also capture non-schema objects and privilege grants.
Finally, you can capture individual schema objects by specifying the type, schema and name of each object. This form of scope specification is appropriate when you want to capture a few specific objects, rather than all objects contained within one or more schemas. While capturing individual schema objects, you can also capture non-schema objects and privilege grants.
If you include a non-schema object type, such as User or Role, in a scope specification, all objects of that type are captured. There is no way to capture individual non-schema objects. Figure 7-1 shows the Dictionary Baselines:Objects page where the scope can be specified.
Figure 7-1 Baseline Scope Specification in the form Of Schemas And Object Types to Capture
As the final step of defining a baseline, you specify when to capture the first version of the baseline. You can capture the first version immediately, or at a later time (for example, when the database is not being used in active development work). You can also indicate that additional versions of the baseline should be captured at regular intervals without further intervention on your part.
You can also capture a new baseline version at any time by selecting the baseline and specifying "Recapture Now."
Baselines processed after the initial version generally complete substantially faster than the initial version. Only those objects that have changed are captured in the new version. This also means that the storage required for additional baseline versions is only slightly larger than the storage used by the initial version, assuming a small percentage of objects has changed. Figure 7-2 shows the first version of a dictionary baseline.
Figure 7-2 A Baseline Viewed After Completion of the Capture of the First Version
Within a single dictionary baseline version, you can examine individual object attributes, generate DDL for individual objects, and generate DDL for all the objects in the baseline version. You cannot modify object definitions captured in baseline versions, since they are intended to represent the state of objects at a particular point in time.
Viewing a baseline object displays the object's attributes graphically.
Selecting a baseline object and specifying "Generate DDL" displays the DDL used to create the object. Figure 7-3 shows the DDL generated for a baseline object.
Figure 7-3 DDL Generated for a Selected Baseline Object
Selecting a baseline version and specifying "Generate DDL" generates the DDL for all objects in the baseline version. While an effort is made to create objects in the correct order (for example, creating tables before indexes), the resulting DDL cannot necessarily be executed on a database to create the objects in the baseline version. For example, if you capture all the schema objects contained in schema APPL1, then try to execute the baseline version DDL on a database that does not contain User APPL1, the generated DDL will fail to execute.
Baseline versions are also used with other Change Management Pack applications, such as Compare and Synchronize. You can compare a baseline version to a database (or to another baseline version). You can also use a baseline version as the source of object definitions in Synchronize, allowing you to re-create the definitions in another database.
When a baseline contains more than one version, you can examine the differences between the versions.
To see what has changed between a version and the version that precedes it, select the version and specify "View Changes Since Previous Version." The display shows which objects have changed since the previous version (Figure 7-4), which have been added or removed, and which are unchanged. Selecting an object that has changed displays the differences between the object in the two versions.
Figure 7-4 Viewing Changes SInce the Previous Version
To see how an individual object has changed over all the versions of the baseline, select the object and specify "View Version History." The display identifies the versions in which the object was initially captured, modified, or dropped as shown in Figure 7-5. From this display, you can compare the definitions of the object in any two baseline versions.
Figure 7-5 Viewing Version History of a Selected Baseline Object
A dictionary comparison identifies differences in database object definitions between a baseline or a database and a baseline or a database, or two schemas within a single database/baseline.
A comparison specification is defined by left and right sources, scope, and owner. The scope specification describes the names and types of database object definitions to be included in the comparison and the schemas that contain these object definitions.
Comparisons identify differences in any attribute value between objects of any type. Use comparisons to create multiple versions of a comparison. Each version has a unique version number and a comparison date. Use these versions to associate comparisons of database/schemas made over time.
Comparisons show differences between definitions in the original baseline for your application and those in your current database. After creating a new comparison version, it identifies the differences between the original definitions at the start of the development cycle, and those same definitions at the current time.
Use another comparison specification to compare definitions from your most recent baseline with those in your previous baseline. With each newly created version of this comparison using the comparison specification, that comparison version identifies the differences in the definitions since the previous baseline.
A dictionary comparison definition consists of left and right sources for metadata definitions, the scope specification, an optional schema map, and comparison options. Once created, a dictionary comparison definition cannot be modified. This ensures that each version of the dictionary comparison reflects changes in the databases being compared and not in the comparison's definition.
Each comparison has a left source and a right source. The comparison matches object definitions from the left and right sources. A source can be a database or a baseline version.
When the source is a database, object definitions are taken directly from the database at the time the comparison version is created.
When the source is a baseline, object definitions are taken from the specified baseline version. Using a baseline version allows you to compare a database (or another baseline version) to the database as it existed at a previous point in time. For example, a baseline version might represent a stable point in the application development cycle, or a previous release of the application.
For baseline sources, there are various ways to specify the version to be used.
If you want a specific baseline version to be used in all versions of the comparison, specify the baseline version number. This is appropriate for comparing a well-defined previous state of the database, such as a release, to its current state.
You can also request that the latest or next-to-latest version be used in the comparison. If you specify "Latest," you can also request that the baseline version be captured before the comparison takes place. This option allows you to capture a baseline and compare it to the other source in a single operation. For example, every night, you can capture a baseline version of the current state of a development database and compare it to the previous night's baseline, or to a fixed baseline representing a stable point in development.
The scope specification for a dictionary comparison identifies the objects to compare in the left and right sources. Creating a comparison scope specification is the same as creating a baseline scope specification, described in the "Dictionary Baselines" section. As with baselines, you can specify object types and schemas to compare, or individual objects to compare.
Normally, schema objects in one source are compared to objects in the same schema in the other source. For example, table APPL1.T1 in the left source is compared to APPL1.T1 in the right source.
However, there may be cases where you want to compare objects in one schema to corresponding objects in a different schema. For example, assume that there are two schemas, DEV1 and DEV2, which contain the same set of objects. Different application developers work in DEV1 and DEV2. You can use the optional schema map feature to allow you to compare objects in DEV1 to objects with the same type and name in DEV2.
To add entries to the schema map, expand the "Mapped Objects" section of the comparison "Objects" page. You can create one or more pairs of mapped schemas. Each pair designates a left-side schema and a corresponding right-side schema.
When using a schema map, you can compare objects within a single database or baseline version. In the example above, DEV1 and DEV2 can be in the same database. You specify that database as both the left and right source, and supply the schema map to compare objects in DEV1 to those in DEV2.
You can select several options to determine how objects are compared. These options allow you to disregard differences that are not significant. The options include the following:
"Ignore Tablespace" and "Ignore Physical Attributes" – These two options allow you to compare stored objects without regard to the tablespaces in which they are stored or the settings of their storage-related attributes. This is useful when you are comparing objects in databases having different size and storage configurations, and you are not interested in differences related to the storage of the objects.
"Match Constraints By Definition" or "By Name" – If you are more interested in the definitions of table constraints – for example, the columns involved in primary or unique constraints – choose "Match Constraints By Definition." This causes constraints with the same definitions to match; their names appear as differences (unless you also choose "Ignore Name Differences"). If the names of constraints are meaningful, choose "Match Constraints By Name." With this choice, constraints with the same names will match and their definitions will appear as differences.
"Partitioned Objects: Ignore High Values" – Tables that are otherwise the same might have different partition high values in different environments. Choose this option to ignore differences in high values.
"Logical SQL Compare" – Choose this option to ignore meaningless formatting differences in source objects such packages, package bodies, procedures and functions.
"Compare Statistics" – Choose this option to compare optimizer statistics for tables and indexes.
"Ignore Table Column Position" – Choose this option if tables that differ only in column position should be considered equal.
When you have finished defining the comparison, you specify when to create the first comparison version. You can create the first version immediately, or at a later time. You can also schedule new comparison versions at regular intervals.
In addition to scheduling comparison versions, you can create a new comparison version at any time by selecting the comparison and specifying "Repeat Now."
Comparisons processed after the initial version generally complete substantially faster than the initial comparison. Only those objects that have changed on the left or right side are compared in the new version. This also means that the storage required for additional comparison versions is only slightly larger than the storage used by the initial version, assuming a small percentage of objects has changed.
A dictionary comparison version records the results of comparing the left and right sources in accordance with the scope specification. Objects in a comparison version have one of four states:
Left Only – The object is present only in the left source.
Right Only – The object is present only in the right source.
Identical – The object is present in both left and right sources, and is the same.
Not Identical – The object is present in both left and right sources, and is different.
Figure 7-6 Comparison Version Page Showing a List Of Not Identical Objects
The page lists all versions of a comparison shows the number of objects in each state within each version. On the Comparison version page shown in Figure 7-6, you can see the objects in each state individually. Objects that are "Not Identical" can be selected to view the differences, and to generate DDL for the left and right definitions as shown in Figure 7-7.
Figure 7-7 Viewing Differences in the Attributes of a Selected Not Identical Object
You can take two further actions to record information about objects in a comparison version:
You can add a comment to an object. For example, the comment might explain why two objects are different.
You can ignore the object. Ignoring the object removes it from lists of comparison version objects. You might ignore an object that is different if you decide that the difference is not important.
A dictionary synchronization synchronizes differences in database object definitions between two databases or a baseline and a database. The basic action of a database synchronization is to create or modify selected object definitions in a database to match those in another database or in a baseline.
Synchronizations are generated using synchronization specifications. For synchronizations, the scope specification does not include the names of individual objects. It can only specify the types, and the schemas to be included or excluded. You can additionally supply a prefix to limit the objects selected to those whose names start with that prefix.
Dictionary synchronizations synchronize differences in any attribute value between objects of any supported type. Use synchronization specifications to create multiple versions of a synchronization. Each version has a unique version number and a synchronization date. Use these versions to associate synchronizations of database/schemas made over time.
The synchronization source provides the object definitions (and optionally, the data) from which the destination database is synchronized. A synchronization source may be a database, or a baseline version. If the source is a baseline version, it is not possible to propagate data to the destination, since a baseline does not capture data.
The synchronization destination must always be a database. The purpose of synchronization is to create or modify object definitions in the destination to match those in the source.
The options for specifying which version of a source baseline to use are similar to those used with dictionary comparisons. You can specify a fixed baseline version, or "Latest" or "Latest-1". If you specify "Latest," you can also request that the baseline version be captured first before synchronizing the destination from it.
When defining a baseline to be used as the source for synchronization, it is important that the baseline contain all the objects to be synchronized. For this reason, the baseline's scope specification should include at least all the schemas and object types that will be synchronized. The baseline should also include User and Role objects, along with privilege grants. A baseline to database synchronization is recommended in environments where changes are expected to be applied to the source database frequently thus necessitating the need for a point-in-time snapshot of the database, i.e. a baseline as the source of the synchronization.
Defining a scope specification for a dictionary synchronization is similar to defining a scope specification for a dictionary baseline or comparison. However, there are restrictions on what you can include in the scope specification.
You cannot specify individual objects for synchronization. You must specify object types and either schemas to include or schemas to exclude.
Certain schemas, such as SYS and SYSTEM, cannot be synchronized.
You cannot directly include User and Role objects for synchronization. (However, Users and Roles are automatically included as needed during the synchronization process.)
The following object types must be selected as a group: Table, Index, Cluster, Materialized View, and Materialized View Log.
The scope specification for a synchronization should be carefully tailored to the application. Do not include more schemas than are needed. For example, if you are synchronizing a module of a large application, include only those schemas that make up the module. Do not attempt to synchronize a large application (or the entire database) at one time.
The definition and use of the schema map is the same in dictionary synchronizations as in dictionary comparisons. When you use a schema map, object definitions in each schema map are synchronized to the mapped schema in the destination, rather than to the schema with the same name. In addition, schema-qualified references (other than those contained in PL/SQL blocks and view queries) are changed according to the schema map.
For example, assume the schema map has two entries, as follows:
DEV1A -> DEV2A
DEV1B -> DEV2B
Table DEV1A.T1 has an index, DEV1A.T1_IDX. It also has a foreign key constraint that refers to DEV1B.T2. Synchronize will create objects as follows:
Table DEV2B.T2
Table DEV2A.T1, with a foreign key reference to table DEV2B.T2
Index DEV2A.T1_IDX, on table DEV2A.T1
Dictionary synchronization options are similar to the options you can specify with dictionary comparisons. In synchronization, the options perform two functions:
During initial comparison of source and destination objects, the options determine whether differences are considered meaningful. For example, if the "Ignore Tablespace" option is selected, tablespace differences are ignored. If two tables are identical except for their tablespaces, no modification to the destination table will occur.
When generating the script that creates objects at the destination, some options control the content of the script. For example, if "Ignore Tablespace" is selected, no TABLESPACE clauses are generated.
In addition to the options provided with dictionary comparison, the following options are specific to Synchronize:
"Preserve Data In Destination" and "Copy Data From Source" – These two options control whether table data is copied from the source database to the destination database. (The option is not available if the source is a baseline.) By default, Synchronize preserves data in destination tables. Choosing "Copy Data From Source" causes Synchronize to replace the destination data with data from the source table.
"Drop Destination-Only Schema Objects" – Choosing this option directs Synchronize to drop schema objects that are present in the destination but not the source. For example, if the source contains table DEV1.T1 and the destination contains DEV1.T1 and DEV1.T2, Synchronize will drop DEV1.T2 if this option is chosen. This action applies only to schema objects that are within the scope specification. By default, Synchronize does not drop destination-only objects. Synchronize never drops non-schema objects.
The next step in defining a synchronization is to choose the synchronization mode. There are two options:
Unattended synchronization mode carries out the entire synchronization process in one step, ending with execution of the synchronization script. However, if an error is detected that makes it impossible to generate a correct script, the process will terminate without attempting to execute the script.
Interactive synchronization mode pauses after initial comparison of the source and destination objects, and again after generation of the synchronization script. Interactive mode gives you a chance to examine the results of comparison and script generation, and to take appropriate action before proceeding with the next step.
Creating Synchronization Versions
When you have finished defining the synchronization, you specify when to create the first synchronization version. You can create the first version immediately, or at a later time. You can also schedule new synchronization versions at regular intervals.
Depending on the synchronization mode you select, the synchronization may run to completion (unattended mode), or pause after initial object comparison (interactive mode). In the latter case, you run each subsequent phase of the synchronization in a new job.
When using interactive mode, the destination database should not be modified from the time the objects are initially compared until the synchronization script has executed. Otherwise, the script may encounter problems. For example, assume the source has a table that the destination does not have. Object comparison notes the source-only table, and the generated script includes statements to create the table. However, after object comparison but before script execution, you manually create the table at the destination database. The script will fail when it attempts to create the table because the table already exists.
Figure 7-8 shows a list of synchronizations.
For more information about the process of synchronization, see Working with Dictionary Synchronization Versions.
You can use a dictionary comparison as the starting point for synchronization. Select the comparison, then choose "Synchronize." This creates a new synchronization with the following initial information from the comparison:
Source and destination, from the comparison's left and right sources, respectively. This means that you cannot create a synchronization from a comparison whose right source is a baseline.
Scope specification. Note that some comparison scope specification options are not available in a synchronization. For example, you cannot synchronize individual schema objects, User objects, or Role objects.
Comparison options
Each synchronization version represents an attempt to modify the destination objects selected by the scope specification to match the corresponding source objects. (It is "an attempt" because the process may not complete, for various reasons.) This section describes how a dictionary synchronization version is processed, and how you can monitor and control the process.
There are three steps involved in processing a synchronization version. As noted previously, you can combine these steps into one (by choosing "Unattended Mode") or run each step separately (by choosing "Interactive Mode"). In either case, all three steps must be carried out when processing a successful synchronization version.
The following sections detail each of the three steps and describe what you can do following each step, when operating in interactive mode.
The first step is to compare objects in the source to corresponding objects in the destination. Only those objects selected by the scope specification are compared. At the end of this step, the synchronization version has recorded all the objects. Each object is in one of the following states:
Source Only
Destination Only
Identical
Not Identical
In interactive mode, you can view the objects that are in each state, or all objects at once. For objects that are not identical, you can view the differences between the objects. At this stage, you can anticipate what will happen to each destination object:
Source-only objects will be created in the destination.
Destination-only objects will be unaffected, unless you chose the "Drop Destination-Only Schema Objects" option, in which case they will be dropped from the destination.
Identical objects will be unaffected. However, if you chose the "Copy Data From Source" option, the data in tables that are identical will be replaced with data from the source.
Non-identical objects will be modified to match the source object. Depending on the differences, the modification may be done with ALTER statements or by dropping and re-creating the object.
Before proceeding to script generation (Figure 7-9), you can exclude objects from the synchronization. For example, if you notice a source-only view that you do not want to create at the destination, you can exclude it now.
Figure 7-9 Continue to Script Generation Step in the Interactive Mode
During script generation, Synchronize uses the results of the comparison step to create the PL/SQL script that will create and modify objects at the destination so that it matches the source. As part of script generation, several activities take place:
Dependency analysis assures that the destination database provides a suitable environment for each object and that objects are created and modified in the correct order.
Change analysis determines whether an object can be modified with ALTER statements or if it must be dropped and re-created.
Messages are placed in the impact report for the synchronization version. The messages provide information about the synchronization process, and may report one or more error conditions that make it impossible to generate a usable script.
The DDL statements needed to carry out the synchronization are generated and recorded in the synchronization version.
Dependency analysis examines each object to determine its relationships with other objects. It makes sure these other objects exist (or will be created) in the destination. Some examples of these relationships are:
A schema object depends on the User object that owns it. For example, table DEV1.T1 depends on user DEV1.
An index depends on the table that it is on. For example, index DEV1.T1_IDX depends on table DEV1.T1.
A table that has a foreign key constraint depends on the table to which the constraint refers.
A source object such as a package body depends on other source objects, tables, views, and so on.
A stored object depends on the tablespace in which it is stored, unless you choose "Ignore Tablespace."
The relationships established during dependency analysis are used later in the script generation process to make sure script statements are in the correct order.
Dependency analysis may determine that a required object does not exist in the destination database. For example, a schema object's owner may not exist in the destination database. Or, a table may have a foreign key constraint on another table that is in a different schema. There are several possible outcomes.
If the required object is in the source and is selected by the scope specification, Synchronize creates the object. For example, if DEV1.T1 has a foreign key constraint that refers to DEV2.T2, and both DEV1 and DEV2 are in the scope specification, Synchronize creates DEV2.T2.
If the required object is a user or role, and the object is available in the source, Synchronize automatically includes the user or role and creates it at the destination. This occurs even though User and Role objects are not part of the Synchronize scope specification.
If a required schema object is in the source but is not selected by the scope specification, Synchronize does not automatically include the object; instead, it places an Error-level message in the impact report. This restriction prevents uncontrolled synchronization of objects outside the scope specification. It is for this reason that scope specifications should include all the schemas that make up the application or module.
If the source is a baseline version, it may not include the required object. For example, a baseline might not capture Users and Roles. Synchronize cannot look for objects outside the baseline version, so it places an Error-level message in the impact report as shown in Figure 7-10. This is why it is important to include Users, Roles, and privilege grants in any baseline that will be used for synchronization.
Figure 7-10 Error-level Impact Report Messages Resulting from a Required Schema Object Not Selected by the Scope Specification
At the end of the script generation step, Synchronize has added the impact report and the script to the synchronization version. In interactive mode, you can examine the script and impact report before proceeding to script execution.
The impact report contains messages about situations that were encountered during script generation. There are three types of messages:
Informational messages require no action on your part. They simply report something of interest. For example, when script generation automatically includes a User object, it adds an informational message to the impact report.
Warning messages report a situation that requires your attention, but that may not require action. For example, if Synchronize is unable to determine if a reference is a source object can be resolved, it adds a warning message to the impact report. You need to verify that situations reported in warning messages will not prevent script execution.
Error messages indicate a situation that will prevent script execution if not corrected. For example, if Synchronize is unable to locate a required dependency object, it adds an error message to the impact report. Depending on the message, you may be required to create a new synchronization. For example, if the dependency object is not in the synchronization scope, or if the source is a baseline that does not contain the dependency object, you will need to create a new synchronization with an expanded scope or a different source baseline. In other cases, you can resolve the situation by excluding one or more objects from the synchronization and regenerating the script.
The script display contains the statements of the generated script in the order they will be executed. You can examine the script if you have any concerns about its correctness. The display allows you to locate statements that are associated with a particular object or object type.
Figure 7-11 Continuing To Script Execution Step in the Interactive Mode (Impact Report Tab)
Following script generation, you can continue to script execution unless an error was encountered during the script generation step (Figure 7-11 and Figure 7-12). In this case the impact report will contain one or more Error-level messages detailing the problem and solution. In some cases, you may be able to solve the problem by selecting "Regenerate Script," excluding an object from the synchronization, and regenerating the script.
Figure 7-12 Continuing To Script Execution Step in the Interactive Mode (Script Tab)
There may be cases where you need to create a new version of the synchronization in order to correct the problem. For example, if you need to modify the definition of an object in the source or destination or add an object in the destination, you will need to create a new version. This allows the new or modified object to be detected during the comparison step. In this case, the old version becomes "abandoned" since you cannot continue to script generation.
Following successful script generation, the script is ready to execute. In unattended mode, the script executes as soon as script generation completes. In interactive mode, you proceed to script execution as soon as you have reviewed the impact report and the script.
The script executes in the Enterprise Manager job system. Figure 7-13 shows the output of the Synchronization job. Once script execution is complete, you can view the execution log. If the script fails to execute successfully, you may be able to correct the problem and re-start the script execution from the point of failure. For example, if the script fails due to lack of space in a tablespace, you can increase the size of the tablespace, then re-start the script.
Figure 7-13 Synchronization Script Execution Step Output of Enterprise Manager Job
Following processing of the initial synchronization version, you can create additional versions of the synchronization. Select the synchronization, then choose "Synchronize Again." Note that you cannot choose a different source or destination, or modify the scope specification or synchronization options, when creating a new synchronization version. However, you can choose a different mode (Unattended or Interactive) when starting a new synchronization version.
Creating additional synchronization versions allows you to propagate incremental changes in the source to the destination. For example, you can refresh a test database from the latest changes made to a development system.
Synchronizations processed after the initial version generally complete substantially faster than the initial synchronization.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
