Oracle Designer Repository Installation Guide  
Contents icon
Contents

PrevNext

Server-Side Installation, Migration and Upgrade

This section describes how to install a new repository, how to migrate data from a repository installed under a previous release, and how to upgrade a repository that was installed under a recent release. The following topics are covered: This section is intended for use by Oracle database administrators (DBAs) and requires knowledge of SQL and Oracle database management.

Caution:

Do not use any of the procedures in this section unless you have first installed Oracle Designer or Oracle Designer Repository at a client workstation. 


System Requirements

The Operating Systems and Database server versions certified for use with Oracle Designer are listed on Metalink (metalink.oracle.com)

The client workstation and the database server can be on the same machine (Windows only), or on different machines.

System requirements for a client workstation are listed in the Oracle Developer Suite Installation Guide. System requirements for the database server are listed in the Oracle Database Installation Guide. Additional requirements for the database server are:


Note:

If you are migrating from a release 6.0 repository, the database that is to host the release 6i repository must have the Distributed Option installed. 

For Oracle Designer running against an Oracle9i or Oracle8i Standard Edition database, Server Generator will not be able to generate bitmap indexes, function-based indexes or materialized views 


Planning a New Repository

If you are installing a brand-new repository, you need to take a number of decisions about its features before you begin the repository installation process. You will be prompted for the following information during installation: In addition, you need to consider the following at this stage:

Repository Size

During installation you are asked to specify the repository size as Small, Medium or Large in order to set appropriate tablespace sizes.

As an approximate guide, a small repository might contain up to 20,000 element definitions, a medium repository up to 100,000 element definitions and a large repository more than 100,000 element definitions. If you are installing a production repository, use these figures to make your choice unless you believe your requirements will be significantly different. If you are just installing a repository for evaluation purposes, choose Small.

If you choose Small, tablespaces are created with default initial extent and next extent values of 100K. Choosing Medium or Large will increase the initial extent and next extent values for all tablespaces except SYSTEM and TEMPORARY.

Tablespace Details

SQL Script Method

The SQL script method creates tablespaces with the default names and sizes as shown in the table for the manual method below. You can, however, modify these details before you run the CKCREATE script, as described later in the section on installing using the script method.

Manual Method

If you use the manual method, you will create tablespaces manually as part of the installation procedure.

For a production repository, we recommend that you create the dedicated tablespaces with the sizes as shown in the table below.

For a repository that is to be used purely for evaluation or trial purposes, you may just want to create two tablespaces, one for the indexes and one for the tables. In this case, use the sizes indicated in the table against "Total for index tablespaces" and "Total for table tablespaces" respectively (note that you can use this technique only with the manual method).

We also recommend using the tablespace names shown or similar easily identifiable names, as you will need to select them individually later.

The following table shows the minimum tablespace sizes in KB for small, medium and large repositories:

 
Tablespace name
Minimum tablespace size (KB)
Small 
Medium 
Large 
CONSTANT_GROW_INDEXES
2048 
7030 
11000 
CONSTANT_GROW_TABLES
2048 
4440 
9000 
DEPENDENCY_INDEXES
10240 
23000 
30000 
DEPENDENCY_TABLES
2048 
4560 
9600 
DIAGRAM_INDEXES
4096 
4680 
10000 
DIAGRAM_TABLES
2048 
2048 
2640 
LOB_DATA
1024 
2048 
5000 
RAPID_GROW_INDEXES
303104 
1148440 
1750000 
RAPID_GROW_TABLES
89200 
235200 
463000 
SYSTEM_META_INDEXES
30720 
30720 
30720 
SYSTEM_META_TABLES
20480 
20480 
20480 
TEMPORARY_INDEXES
10240* 
20000* 
20000* 
TEMPORARY_TABLES
10240* 
10240* 
10240* 
VERSION_INDEXES
10240 
12000 
40000 
VERSION_TABLES
5600
10800 
19440 
       
Total for index tablespaces: 
370688 
1245870 
1891720 
+ Total for table tablespaces: 
132688 
289816 
539400 
=   Total sum of tablespaces: 
503376 
1535686 
2431120 
       
Additional tablespaces:**      
REPOS_RBS (rollback)
10244 
10244 
10244 
REPOS_TEMP (temporary)
15372 
15372 
15372 
 
* These sizes are based on values for INITIAL and NEXT (see table below) of 100K. If you increase the INITIAL and NEXT values, adjust the sizes for TEMPORARY_INDEXES and TEMPORARY_TABLES proportionately (e.g. if you double the value of INITIAL and NEXT, double the sizes marked *).

** These additional tablespaces are required only if suitable tablespaces do not exist already. For example, for rollback an Oracle9i database using automatic undo can make use of the UNDOTBS1 tablespace installed with the database.


Caution:

The tablespace sizes given above are estimated to ensure completion of the installation and to provide for initial use. More free space will be required for continuing use of the repository.


The minimum free space sizes given in the previous table are based on certain assumptions about the storage parameter values. The following table shows the tablespace storage parameter values assumed for a small repository:
 
Storage parameter Value
INITIAL 100k
NEXT 100k
PCTINCREASE 0
MINEXTENTS 1
MAXEXTENTS unlimited
For medium and large repositories you will need to adjust the storage parameter values accordingly.

Datafile Details

You need to decide the name and location of the datafiles to be used for the various tablespaces that are created. We recommend using a dedicated datafile for each tablespace, with a datafile name that clearly indicates the tablespace to which the file relates, e.g. SCM_CGIND.ORA for CONSTANT_GROWTH_INDEXES.

If you use the manual method of repository installation, you can choose to set AUTOEXTEND on for each datafile when you create it. Doing so avoids the risk of running out of extents during installation, provided that you have sufficient free disk space on the drive.

You can always set AUTOEXTEND on for a datafile after installation is complete, but use this option with care as it allows the size of a file to grow unchecked.

Use of Public Synonyms

Users can access the repository through either private or public synonyms, and you are prompted to choose the access method during installation. (You can change it later using the Repository Administration Utility.)

Public synonyms enable you to give users repository access using just one set of synonyms, instead of creating one set for each user. For each Oracle instance, you can only have one repository accessed using public synonyms because public database objects must be unique.

We strongly recommend using public synonyms. Only use private synonyms for a maximum of 10 users. Using public synonyms maintains repository performance, for example by reducing the time it takes to complete tasks such as reconciling grants for all repository users.

If you choose to use public synonyms, you will need to grant the repository owner the database privileges CREATE PUBLIC SYNONYM and DROP PUBLIC SYNONYM. Under the script method of installation you answer a simple Yes/No prompt for this; under the manual method you must grant these privileges explicitly.

For more information about repository use of private and public synonyms, look in the Repository Management online help index under "synonyms".

Use of Version Control

Version control is the process of maintaining multiple versions of software development objects and is a fundamental requirement if you are using the repository for software configuration management.

Although you do not need to specify during installation whether to enable version control, it is a good idea to consider its implications at this stage. Unless it is enabled, you cannot use the software configuration management features of the repository, such as workareas, configurations, check in, check out and merge. However, once version control is enabled you cannot disable it, so you should carefully consider whether it is really necessary for a particular repository and its data.

Installing a New Repository

For new installations under Oracle9iDS, you must install a new repository on an existing database. Because no preconfigured repository is supplied with this release, you must define the tablespace sizes and allocations as part of the installation.

The installation process can take several hours to complete, depending on the speed of the server, the client and the connections between them.

There are two methods of installing a new repository:

With the SQL script method, the installation process is semi-automated; you run a series of SQL scripts, which prompt you for any necessary input. You can also change the input parameters before you run the script that creates the repository tablespaces and other objects.

With the manual method, you create everything by entering individual SQL statements. This takes longer than the script method, but allows you a greater degree of control over the installation process.

Both methods require you to execute a series of pre-installation procedures, and also involve running the Repository Administration Utility to complete the installation process.

Pre-Installation Procedures

Whether you will be installing by the script method or the manual method, you must perform the following steps first, at the database server:

Step 1 - Log On to the Machine That Hosts the Oracle Database
Step 2 - Ensure Correct Settings for Database Initialization Parameters
Step 3 - Start or Restart the Oracle Database If Necessary
Step 4 - Ensure That TNS Listener Is Started
Step 5 - Oracle 9i Servers only: Install Oracle 9i Import and Export Utilities

Step 1 - Log On to the Machine That Hosts the Oracle Database

Log on to the machine that hosts the Oracle database you will be using for the repository.

Step 2 - Ensure Correct Settings for Database Initialization Parameters

Oracle9i Databases Using a Server Parameter File
With Oracle9i the initialization parameters are typically managed by a server parameter file (SPFILE), a binary file that resides in the database Oracle home on the server in the following default location:
Oracle_home\database (Windows servers)
$ORACLE_HOME/dbs (UNIX servers)
If the database is using a server parameter file that does not have the settings shown under "Set the Database Initialization Parameters" later in this section, you will need to do the following before proceeding:
  1. Start SQL*Plus.

  2.  
  3. Connect as SYS using the AS SYSDBA clause (for example SYS/psw@alias AS SYSDBA).

  4.  
  5. At the SQL> prompt, enter:
  6. alter system set param_name = param_value [,param_name = param_value ...] 
    scope = spfile;
    where param_name and param_value are the name and value of an entry in the SPFILE.
     
  7. Exit from SQL*Plus.
See the Oracle9i Database Administrator's Guide for full details about managing initialization parameters using a server parameter file.
Oracle9i Databases Using INIT.ORA
Parameters for configuring the Oracle database at startup are contained in a file named INIT.ORA. This step checks the setting of the relevant parameters and changes them where necessary.

Read "Set the Database Initialization Parameters" later in this section. This contains important information to help you set the parameters to the correct values for your installation.

Find the INIT.ORA file, which should be at:

database_Oracle_home\ADMIN\dbname\PFILE\INIT.ORA
where database_Oracle_home is the location to which the Oracle database was installed, and dbname is the database name (e.g. the name portion of the name.domain global database name).

If there is more than one Oracle database instance on the server, make sure that you locate the correct file.

Using a text editor or similar program, open the INIT.ORA file, check the current settings and make any necessary changes to the file.

When you have finished, save your changes and close the INIT.ORA file.

Step 3 - Start or Restart the Oracle Database If Necessary

If the database is not already started, start it now.

If the database is already started and you changed the INIT.ORA file in the previous step, shut down and restart the database.

Step 4 - Ensure That TNS Listener Is Started

You need to have a TNS Listener service running. This is a utility that handles database connection requests.

Under Windows, click Start > Settings > Control Panel > Services. In the Services dialog box, if the service named Oracledatabase_Oracle_homeTNSListener does not show "Started" in the Status field, select this service and click the Start button (where database_Oracle_home is the location to which the Oracle database was installed).

Under UNIX, enter the command lsnrctl status. Under the heading "Services Summary...", check that there is an entry reading "database_name has 1 service handler(s)." If there is no entry for the desired database, then at the LSNRCTL> prompt, enter the command start. When this has completed successfully, enter the command status and check again.

Step 5 - (Oracle 9i only) Install Oracle 9i Import and Export Utilities

Before installing Designer Repository on an Oracle 9i database, you need to set up the installation workstation to use the Oracle 9i import and export utilities. To do so, perform the following steps at the workstation from which you will be running the repository installation:
  1. From the Oracle 9i installation media, install the Oracle 9i import and export utilities in a dedicated Oracle home.
  2. In the Windows Registry, locate the key named:
  3. For Designer 10g - 9.0.4.x
    HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn\REPOS61

    Designer 10g R2 onwards
    HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_HomeName\REPOS61

    where KEY_HomeName/ HOMEn is the home name of the oracle home where Designer is installed for a multiple Oracle home environment, but is not present where the default Oracle home is being used.

    Change the value of the EXECUTE_IMPORT and EXECUTE_EXPORT variables to point to the new Oracle home. Thus, if the new Oracle home is d:\des_9i, the settings would be:

    d:\des_9i\bin\exp.exe
    d:\des_9i\bin\imp.exe

Installing a Repository (SQL Script Method)

The SQL scripts available are shown, with a brief description, in the following table:
 
Script Description
ckqa Collects input from you for passing on to subsequent scripts. Input is placed in a file named CKPARAMS.TXT, which you can edit before continuing with further scripts.
ckvalqa Validates the user input collected during the ckqa stage. You need to run this script only if you have modified the CKPARAMS.TXT file since you last ran ckqa.
ckcreate Creates the database objects required by the repository. Also creates the repository owner with the necessary privileges.
ckcreate_mb Same as ckcreate, but for use with a multibyte character-set database.
ckreport Creates a report (in the file CKREPORT.LST) on the database objects created by ckcreate or ckcreate_mb. 
ckclean Removes the repository, deleting all the database objects created by ckcreate or ckcreate_mb.

To install a new repository using the script method:

  1. If you have not done so already, perform the pre-installation procedures.

  2.  
  3. Open a Command Prompt window and set the current directory to the one where the scripts are stored:
  4. cd d:\Oracle_home\repadm61\admin
    where Oracle_home is the Oracle home directory where the client tools were installed.
     
  5. From the Command Prompt window, start SQL*Plus:
  6. d:\Oracle_home\bin\sqlplus
  7. At the "Enter user-name:" prompt, enter the full connect string in the form:
  8. sys/psw@host [as sysdba]
    The AS SYSDBA clause is mandatory for an Oracle9i database.
     
  9. At the SQL> prompt, enter:
  10. @ ckqa
    This script creates a file named CKPARAMS.TXT (in the same directory as the script files), based on the input you supply while the script is running.

    The script displays a number of prompts, for which the responses are shown in the following table:
     
    Prompt Response
    Enter TNS connect string for server
    The database alias (same as the host string in step 4).
    Enter password for SYS
    The password for the SYS user (same as psw in step 4).
    Enter the repository size you wish
    to create...
    S, M or L for a small, medium or large repository (see Repository Size earlier in this chapter).
    Dropping temporary table CKRAU_TEMP
    None needed; ignore any message of the form "ORA-00942: table or view does not exist."
    Enter datafile location and name for
    tablespace
    The name, and optionally the location, of the datafile for the repository tablespace indicated. Use a datafile name that clearly indicates the tablespace to which the file relates, e.g. SCM_CGIND.ORA for CONSTANT_GROWTH_INDEXES. The default location is database_Oracle_home\DATABASE. To store the datafiles in a different location, enter the full pathname and file name.
    For ten or more subordinate users, we
    recommend giving access using public
    synonyms. Do you wish to grant create/drop
    public synonym privilege to Repository
    Owner?
    Y (recommended - see Use of Public Synonyms earlier in this chapter).
    Hit enter to Continue with validation
    process...
    Press ENTER. The script then validates your input. 
    Please verify the above values. Edit
    'ckparams.txt' to make any changes.
    Then run ckparams.txt.
    Review the values listed on the screen. These will be the input for the ckcreate script. You should not normally need to change any of these values, but if you do want to make changes (e.g. to increase the size of a tablespace) continue with step 6, otherwise go on to step 7.

  11. (Optional) If you want to make any changes to the parameter values, edit the file CKPARAMS.TXT, then save and close it.

  12.  

    Run CKPARAMS.TXT by entering the following in the SQL*Plus window:

    @ ckparams.txt
    Validate the changes by entering the following:
    @ ckvalqa
  13. Enter the following:
  14. @ ckcreate[_mb]
    where the "_mb" extension is for use only with a multibyte character-set database.

    Ignore any message of the form "ORA-01919: role 'CK_ORACLE_REPOS_OWNER' does not exist".
     

  15. (Optional) Run the report to list the database objects created:
  16. @ ckreport
    The report output is stored in the file CKREPORT.LST in the same directory as the script files.
     
  17. Exit from SQL*Plus and continue with the manual method at the point where you start the Repository Administration Utility. Note that the scripts create the repository owner with the username REPOS_MANAGER and the password MANAGER. We recommend that you change the password as soon as possible after installation is complete.

Installing a Repository (Manual Method)

Step 1 - Perform Pre-Installation Procedures

If you have not done so already, perform the pre-installation procedures at the database server.

The remaining steps take place at the client workstation from which you will be running the repository installation. The current release of Oracle Designer 10 g or Oracle Designer Repository client software must be installed at this workstation.

Step 2 - Create Tablespaces for the Repository Tables and Indexes

For a production repository, we recommend that you create dedicated tablespaces as indicated earlier under "Tablespace Details". Proceed as follows:
  1. Start SQL*Plus at the client.

  2.  
  3. Connect to the database as SYS (for an Oracle9i database, use the AS SYSDBA clause, for example SYS/psw@alias AS SYSDBA).

  4.  
  5. To create a new tablespace, enter:
create tablespace tbs_name datafile ‘filespec’ size nnk
default storage (initial nnnk next nnnk minextents n
maxextents unlimited pctincrease n);
where tbs_name is the name of the tablespace, and filespec is the complete file specification for the data file (default location is database_Oracle_home\DATABASE).

Step 3 - Establish an Undo Tablespace or Rollback Segment for the Installation

Oracle9i Databases Using Automatic Undo
If the database is operating in automatic undo mode (UNDO_MANAGEMENT initialization parameter is set to AUTO), undo operations use a dedicated undo tablespace instead of a rollback segment. In many cases, an undo tablespace is created by default (e.g. with the name UNDOTBS) when the database is created. If so, use that tablespace.

If no undo tablespace exists, proceed as follows:

  1. In SQL*Plus, enter:
  2. create undo tablespace tbs_name datafile ‘filespec’ size 10m;
  3. Set the UNDO_TABLESPACE parameter in the database initialization file (SPFILE or INIT.ORA as appropriate) to point to the new tablespace.
Oracle9i Databases Using Manual Undo
You need at least one non-SYSTEM rollback segment for the installation. The rollback segment must be online and have 10 MB free space.

During installation, the Nominate Rollback Segment listbox is disabled and the method described in this step is the only way to ensure a specific rollback segment is used.

You should ensure that the database that will host the repository has sufficient rollback segments to avoid contention for rollback segments. Refer to your Oracle database documentation for information about tuning the database to avoid resource contention.

To create a new tablespace for the rollback segment:

create tablespace tbs_name datafile ‘filespec’ size 10m;
where tbs_name is the name of the tablespace, and filespec is the complete file specification for the data file.

To create the rollback segment and put it online:

create rollback segment rbs_name tablespace tbs_name storage 
(initial 1m next 1m minextents 3 optimal 4m);

alter rollback segment rbs_name online;
where rbs_name is the name of the rollback segment, and tbs_name is the name of the tablespace for the rollback segment.

Step 4 - Check That the SYSTEM Tablespace Has 140 MB of Free Space

The repository packages, procedures and views are stored in the SYSTEM tablespace, and need 140 MB of free space.

To show the size in MB of free space in all the tablespaces, including SYSTEM:

select tablespace_name, sum(bytes)/1024/1024 from dba_free_space 
group by tablespace_name;
If there is not enough free space in the SYSTEM tablespace, you can use one of three methods to increase its size:  resize a data file, add a data file, or use AUTOEXTEND.

To increase the SYSTEM tablespace size by resizing a data file:

alter database datafile ’filespec’ resize nnm;
where filespec is the complete file specification for the data file; nn is the new size in megabytes.

To increase the SYSTEM tablespace size by adding a data file:

alter tablespace system add datafile ’filespec’ size nnm;
To set the AUTOEXTEND option on the current data file used for the SYSTEM tablespace:
alter database datafile ’filespec’ autoextend on;
where filespec is the complete file specification for the original data file used for the SYSTEM tablespace.

Use the AUTOEXTEND method with care, however, as it allows a data file to grow unchecked.

Step 5 - Create the Repository Owner

Create an Oracle user account that will be used for the repository owner and assign a default tablespace and a temporary tablespace to this user.

To see which tablespaces are online:

select tablespace_name, status from dba_tablespaces;
To create the temporary tablespace for the repository owner:
create tablespace temp_tbs_name datafile ’filespec’ size nnk temporary;
where temp_tbs_name is the name of the tablespace; filespec is the complete file specification for the data file; nn is the size in kilobytes (4500k is recommended).

To create the repository owner:
 
 

create user repos_owner identified by password
default tablespace dflt_tbs_name temporary tablespace temp_tbs_name;
where:

Step 6 - Log On to Windows at the Client

If you have not done so already, log on to Windows at the client workstation from which you will be running the repository installation.

Step 7 - Connect to the Database As SYS

To be able to create the repository owner role (as described in the next step), you need to be connected to the database as user SYS.

If you are not already connected as SYS, click the Start button, then choose Programs > Oracle - database_Oracle home > Application Development > SQL Plus.

In the Log On dialog box, fill in the fields as shown in the following table:

 
Field Enter... Notes
User Name  SYS (not SYSTEM)   
Password  The password for SYS   
Host String  database_alias [AS SYSDBA]  The AS SYSDBA clause is mandatory for an Oracle9i database.

Step 8 - Create and Grant the Role CK_ORACLE_REPOS_OWNER for System Privileges

  1. Create a role named CK_ORACLE_REPOS_OWNER for system privileges (you will grant this role to the repository owner later):
  2. @ Oracle_home\repadm61\utl\ckrorole.sql
    where Oracle_home is the directory to which Oracle Designer or Oracle Designer Repository was installed on the client workstation.

    This command runs a SQL script that creates the role CK_ORACLE_REPOS_OWNER and grants it a set of privileges.

  3. Execute the following SQL statements to avoid various potential problems:
  4. grant execute on dbms_rls to repos_owner;
    grant execute on dbms_lock to repos_owner;
    grant execute on dbms_pipe to repos_owner;
    grant create table to repos_owner;
    grant create view to repos_owner;
    grant create procedure to repos_owner;
    grant create synonym to repos_owner;
    grant create sequence to repos_owner;
    grant select on sys.v_$nls_parameters to repos_owner with grant option;
    grant select on sys.v_$parameter to repos_owner;
    grant select on dba_rollback_segs to repos_owner;
    grant select on dba_segments to repos_owner;
    grant create any synonym to repos_owner;
    grant drop any synonym to repos_owner;
    where repos_owner is the username of the repository owner.

    Caution:

    We do not recommend that the repository owner’s account should have the privilege SELECT ANY TABLE if you are installing a repository. This will give users problems when using this product because their account can see repositories for which they have no access. However, users may need the privilege to use specific repository tools or utilities on a repository (for example, registration). 



    Note:

    Take extra care to grant select access correctly on SYS.V_$PARAMETER, otherwise the installation fails at stage CKGLBWRK. This results in an invalid JR_WORKAREA package and a failure to create the global shared workarea and system folder. If this should happen, simply recompiling the package and restarting installation does not cure the problem; a manual workaround is given in the "Troubleshooting" section. 


  5. If applicable, follow the further instructions that are displayed as part of the script.

  6.  

    One consideration will be how to give subordinate users access to the repository. For ten or more subordinate users, we recommend giving access using public synonyms. To enable the repository owner to grant and revoke access using public synonyms, you must make the following grants to the repository owner:

    grant create public synonym to repos_owner;
    grant drop public synonym to repos_owner;
  7. Grant the role to the repository owner:
  8. grant ck_oracle_repos_owner to repos_owner;
  9. Grant connection and resource roles to the repository owner:
  10. grant connect, resource to repos_owner;
    The CONNECT role enables the repository owner to connect to the repository.

    The RESOURCE role grants unlimited quotas to the repository owner on all tablespaces, including SYSTEM.

  11. Close SQL*Plus.

Step 9 - Start the Repository Administration Utility

  1. Click Start and:
    For Oracle Designer 10g - 9.0.4.x

    Choose Programs, Oracle Developer Suite 10gIDS_home, Oracle Software Configuration Manager and then Repository Administration Utility

    For Oracle Designer 10g R2 and above

    Choose Programs, Oracle Developer Suite 10gR2IDS_home, Designer , and then Repository Administration Utility

  2. In the Connect dialog box, fill in the fields as shown in the following table:

  3.  
    Field Enter...
    User Name  The username of the repository owner (indicated by repos_owner in the examples above). If you used the SQL script method to install the repository, the default username is REPOS_MANAGER. 
    Password  The password for the repository owner. If you used the SQL script method to install the repository, the default password is MANAGER. 
    Connect String  The database alias. Make sure that there is an entry for this alias in the TNSNAMES.ORA file in the Oracle home directory where the Oracle database Import and Export utilities are installed. 

Step 10 - Check Privileges, Tablespaces and Parameters

In the Repository Administration Utility, click the Check Requirements button.

Under Parameter Settings, check the parameter settings. If any parameter values are different from those in the table below, set the values in the Windows Registry at the client workstation before continuing. In the table, d: identifies the drive, and Oracle_home the directory, where Oracle Designer or Oracle Designer Repository was installed. All key names shown in the table are preceded by "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\".

The following table shows Windows Registry key names, the parameters relevant to repository installation, and an indication of what each parameter value should be:
Key Parameter Value should be...
CHELP72 HELP72_RAU  d:\Oracle_home\CDOC72\HELP\
CKRAU65.HLP 
REPADM61 EXECUTE_OBJSTAT d:\Oracle_home\BIN\CKOS61.EXE
REPADM61 EXECUTE_REPOSPARAM d:\Oracle_home\BIN\CKCR61.EXE
REPADM61 LOG_DIRECTORY_RAU  d:\Oracle_home\REPADM61\LOGS 
REPADM61 REPADM61  d:\Oracle_home\REPADM61 
REPOS61 EXECUTE_EXPORT  d:\Oracle_home\BIN\EXP.EXE 
REPOS61 EXECUTE_IMPORT  d:\Oracle_home\BIN\IMP.EXE 
REPOS61 EXECUTE_PLUS_RAU  d:\Oracle_home\BIN\SQLPLUS.EXE 
  Working directory  Any writeable directory 

Check also that privileges have been set up as shown in the following table:
Choose To Check Notes
Privileges > Privileges granted for public access System privileges required for subordinate users to access the repository using public synonyms Must have CREATE PUBLIC SYNONYM and DROP PUBLIC SYNONYM if subordinate users are to access the repository using public synonyms; otherwise ignore.
Privileges > Required system privileges  System privileges required to run various operations in the Repository Administration Utility  Must have ALTER SESSION, CREATE DATABASE LINK, CREATE PROCEDURE, CREATE SEQUENCE, CREATE SESSION, CREATE TABLE, CREATE TRIGGER, CREATE TYPE and CREATE VIEW. If enabling and disabling subordinate users, will also need CREATE ANY SYNONYM, CREATE ROLE and DROP ANY SYNONYM. 
Privileges > Roles granted to user  All the database roles that have been granted to the repository owner  Check that CONNECT, RESOURCE and CK_ORACLE_REPOS_OWNER are included in the list. 

If any of the required system privileges or roles are missing, start SQL*Plus, connect as SYS (using the AS SYSDBA clause for an Oracle9i database) and use:

grant name to repos_owner;
where name is the name of the system privilege or role. Restart the Repository Administration Utility and repeat the check.

Under Tablespaces, check whether the SYSTEM tablespace is fragmented (value for Largest Extent is significantly less than that for Free Space).

If the SYSTEM tablespace is fragmented, perform a full database export and re-import using the current version of the Export and Import utilities (EXP and IMP). Restart the Repository Administration Utility and repeat the check.

Close the Check Requirements window.

Step 11 - Select the Type of Repository

  1. On the Repository Administration Utility window, click the Install button (Install) button.
  2. In the Repository Installation Options dialog box, the Support for Repository (Core) Objects box is checked by default. In addition, ensure that the Support for Oracle Designer Objects box is checked (if you will be using Oracle Designer) or not checked (if you will be using Oracle Designer Repository).
  3. Click OK, then respond to the prompt concerning the privilege CREATE PUBLIC SYNONYM if it appears. If the repository is to have ten or more subordinate users, we recommend giving access through public synonyms.

Step 12 - Select the Expected Size of the Repository

In the Install a Repository Instance dialog box, choose the Small, Medium or Large option button.

Choosing Medium or Large will increase the initial extents and next extents values for all tablespaces except SYSTEM and TEMPORARY.

Step 13 - Assign Tablespaces

Repository tables and indexes are stored by default in the tablespace defined as the default tablespace for the repository owner. If you used the SQL script method, this is the TEMPORARY_TABLES tablespace. If you used the manual method, it is the default tablespace defined when you create the repository owner.

You can refine the tablespace assignments by selecting different tablespaces for different categories of repository data.

To assign the tablespaces:

  1. For the indexes, use the dropdown lists under Index Tablespaces as desired.
  2. For the tables, use the dropdown lists under Table Tablespaces as desired.
Tip: Having selected a field on the dialog box, you can select a tablespace quickly by typing its initial letter, repeating this letter if necessary. Use the Tab key to move between fields.

Step 14 - Start the Installation

The installation consists of a number of stages. For each stage, a log file is written to the log directory. These log files are named stage.LIS, where stage identifies a particular stage, for example, CKCONST for the constraint installation stage. You can examine or monitor the log files while the installation is in progress, but do not delete them.

Tip: You might find it useful to view the log directory files in date order so that you can see which ones were created most recently.

To start the installation:

  1. On the Install a Repository Instance dialog box, click the Start button.
  2. Click Yes at the "Do you wish to proceed?" message.
If you see the message:
Insufficient database grant privileges to perform operation.
click the Check Requirements button, proceed as described earlier under "Check Privileges, Tablespaces and Parameters", and then try the installation again.

From this point, the installation process continues automatically, and normally needs no intervention.

If you need to interrupt the process at any point after the Control Status dialog box is displayed, click the Pause buttom (Pause) button.

When you see the message "Operation Complete", click OK followed by Cancel to return to the Repository Administration Utility window.

If the installation appears to complete successfully, examine the log files referred to above to ensure that Oracle errors and warnings were not issued during object creation and compilation. In the Repository Administration Utility, click the View Objects button and make sure that you do not have any invalid, disabled or missing objects in the repository.

If the installation fails at any point, go to the "Troubleshooting" section.

Using NLS Features

If you have a National Language Support (NLS) version of the repository and you want to change the display language for certain types of text, continue from "Setting Up the Repository for NLS Operation", and then return to this point. Otherwise, continue from the next section.

After You Have Installed a Repository

When the installation process has completed successfully, you need to do the following to make the repository ready for use:

Ensure That at Least One Non-SYSTEM Rollback Segment Is Online (Manual Undo Only)

For Oracle9i databases using automatic undo, continue from "Enable Version Control, If Used".

For all other databases, in order to create containers for element definitions, at least one rollback segment that is not in the SYSTEM tablespace must be online. In addition, some of the Repository Object Navigator utilities may involve long-running transactions (for example, the Copy, Delete, Import and Export utilities). These utilities allow users to specify a rollback segment other than the default one, which has a large number of small extents and may not be suitable for these transactions.

For this reason, we recommend that you have at least one non-SYSTEM rollback segment available.


Note:

If you used the script method to install the repository, the rollback segment REPOS_RBS_SEGMENT is automatically created and brought online. 

If you used the manual method and created a rollback segment specifically for the installation, you can use that rollback segment. 


To check the status of the existing rollback segments, start SQL*Plus, connect as the repository owner and enter the following command:
select segment_name, tablespace_name, status from dba_rollback_segs;
If an existing non-SYSTEM rollback segment is suitable but is currently offline, enter:
alter rollback segment rbs_name online;
To create suitable rollback segments, enter:
create rollback segment rbs_name tablespace tbs_name storage
(initial 500k next 500k minextents 3 optimal 4m);
alter rollback segment rbs_name online;
where rbs_name is the name of the rollback segment and tbs_name is the name of the tablespace that will contain it.

To ensure that a rollback segment is brought online whenever the server machine is restarted, add or edit the following line in the INIT.ORA database initialization file (see "Setting the Database Initialization Parameters" ):

rollback_segments = (rbs_name[, rbs_name ...])
If you want to drop an existing tablespace or rollback segment, take it offline, then use the following commands:
drop rollback segment rbs_name;
drop tablespace tbs_name;

Enable Version Control, If Used

If you will be using version control for repository objects, you must enable this feature in the repository.

Caution:

You cannot undo this operation. Before enabling the version control feature, ensure this is really necessary for this repository and its data. If in doubt, defer this operation; you can perform it at any time. See the online help for Repository Management for a full description of the version control functionality. 


To enable version control, proceed as follows:
  1. In the Repository Administration Utility, choose Options > Enable Version Support.
  2. Reply Yes to the "Do you wish to proceed?" message.
  3. Click OK at the "Operation Complete" message.
  4. Read the message about the use of the Repository Object Navigator and click OK.

Test Basic Repository Operations

We recommend testing some of the basic repository operations before making the repository available to other users.

If you are not yet familiar with basic repository operations, we recommend reading the online help topics in the Repository Management help system about creating a default workarea, creating containers, and creating repository objects (that is, element definitions). In addition, if you will be using version control, read the topics about checking in and checking out objects, viewing the version history of an object, comparing object versions, and merging object versions.

When using some of the tools, you may see the message "Unable to register notification service". To stop the message appearing, choose Options > Broadcast Options in the tool and select Disabled.

To test the repository, proceed as follows:

  1. If you have enabled version control, create a new default workarea:

  2.  
    1. Start the Repository Object Navigator by clicking Start and choosing Programs > Oracle Developer Suite - iDS_home > Oracle Software Configuration Management  > Repository Object Navigator (for 10g Designer) or Programs > Oracle Developer Suite - iDS_home > Designer   > Repository Object Navigator
    2. (for 10gR2 and above)
       
    3. Use the same connection details that you used earlier for starting the Repository Administration Utility.

    4.  
    5. Click OK to acknowledge the message about statistics.

    6.  
    7. At the Welcome screen, choose "Invoke Workarea Wizard" and click OK.

    8.  
    9. Create a default workarea using the wizard.

    10.  
    To see the new workarea, you will need to open a new Navigator window at the level of Private Workareas or above.
     
  3. Create a test container in a workarea. (If you have not enabled version control, only one workarea is available.)

  4.  
  5. Create some test element definitions in the new container. Try using different tools to create the definitions.

  6.  
  7. If you have enabled version control:

  8.  
    1. Check in one of the new objects to add it to source control.

    2.  
    3. Check out the object and update some of its properties.

    4.  
    5. Check in the object, ensuring that the version label property is updated (e.g. from 1.0 to 1.1).

    6.  
    7. With the object selected, start the Version History Viewer (choose Version > View Version History) and check that the expected version history displays.

    8.  
    9. In the Version History Viewer, select an object version and compare it (e.g. by Version > Compare Other Version) with another version with known differences.

    10.  
    11. With the object version still selected, merge the version with another (e.g. by Tools > Merge Wizard).
Detailed instructions for carrying out these tasks are in the Repository Management online help.

When using some tools, you may see a message beginning:

Statistics have not been computed for this repository...
You can ignore this message during repository setup or, if you want to stop the message from appearing:
  1. In the Repository Administration Utility, click the Compute Statistics button (Compute Statistics) button.

  2.  
  3. Click Compute (the operation takes a few minutes to complete).

Create Subordinate Users

If other users at your site are to have access to the repository, you will need to create subordinate users. This is the term given to repository users other than the repository owner. Any usernames you want to use for subordinate users must already have been created as Oracle usernames via a CREATE USER statement in SQL*Plus.

You create subordinate users from the Repository Administration Utility. Creating subordinate users requires particular care to ensure that the users have the correct:

For full details of the procedure to create subordinate users, see the topic "Granting repository access to an Oracle user" in the Repository Management help system.

Subordinate users must be assigned the CONNECT and RESOURCE database roles. To do so, start SQL*Plus, connect as SYS (using the AS SYSDBA clause for an Oracle9i database) and issue the following command for each user:

grant connect, resource to username;
If you experience errors when trying to create subordinate users, see "Error Messages When Creating Subordinate Users" in Appendix C.

Grant System Privileges to Users

Various system privileges are required by a repository owner and subordinate users to perform certain repository operations. The following table lists various system privileges, and indicates the operations for which the repository owner or subordinate user will need them:
 
System privilege Repository owner Subordinate user
CREATE SESSION  Connection  Connection* 
ALTER SESSION  Diagnostics  Diagnostics* 
CREATE TABLE  Installation, migration 
CREATE VIEW  Installation 
CREATE SEQUENCE  Installation 
CREATE PROCEDURE  Installation 
CREATE TRIGGER  Installation 
CREATE ANY SYNONYM  Reconcile user   
DROP ANY SYNONYM  Reconcile user   
CREATE PUBLIC SYNONYM Reconcile user  
DROP PUBLIC SYNONYM Reconcile user  
CREATE DATABASE LINK  Migration 
CREATE ROLE  Reconcile user   
CREATE SYNONYM Migration
CREATE ANY TABLE Registration  
CREATE ANY VIEW Registration  
CREATE ANY SNAPSHOT Registration  
CREATE ANY SYNONYM Registration  
CREATE ANY PROCEDURE Registration  
CREATE ANY SEQUENCE Registration  
CREATE ANY TRIGGER Registration  
CREATE ANY INDEX Registration  
CREATE ANY TYPE Registration  
CREATE ANY CLUSTER Registration  
SELECT ANY SEQUENCE Registration  
SELECT ANY TABLE Registration  
* these privileges are granted to subordinate users when they are assigned the CONNECT and RESOURCE roles

Diagnostics privileges are required if, for example, you wish to enable SQL TRACE.

Registration privileges are required for registration of Oracle schemas in the repository. See the online help for Repository Management.

Reconcile user privileges allow subordinate users to be enabled or disabled (synonyms created or dropped) via the Reconcile button on the Maintain Users dialog box of the Repository Administration Utility.

Some subordinate users may need additional privileges depending on which utilities they will be running (e.g. Import/Export from the Repository Object Navigator). To grant these, connect as SYS (using the AS SYSDBA clause for an Oracle9i database) and enter any or all of the following as appropriate:

grant create table to subordinate_user;
grant create view to subordinate_user;
grant create procedure to subordinate_user;
grant create synonym to subordinate_user;
grant create sequence to subordinate_user;
grant select on dba_rollback_segs to subordinate_user;
grant select on dba_segments to subordinate_user;

Grant Access Rights to Users

The user who owns a workarea, container or configuration can grant access rights on that item to other users, or revoke them from those users.

If you have created subordinate users, test the access rights mechanism as follows:

  1. In the Repository Object Navigator, choose File > Access Rights > View Access Rights.

  2.  
  3. Check the current access rights on the test workarea and container that you created earlier.

  4.  
  5. Grant (at least) the Select access right on the workarea and container to one of the subordinate users.

  6.  
  7. Change the connection to that user.

  8.  
  9. Check that the user can see the workarea (under Shared Workareas) and the container.

  10.  
  11. Change the connection back to the repository owner and revoke the access rights.
To grant an access right to all subordinate users (present or future), grant it to PUBLIC.

Note:

If you have enabled version control, remember to grant the Version access right on an object to any users who will be using version control with that object. 


Set Up the Broadcast Server, If Used (Windows Servers Only)

The broadcast server enables repository users to be notified immediately of changes made to repository objects in the current container. Users can use this feature locally (changes made in one tool are immediately visible in other tools) or over the network (same as locally, and in addition changes made by one user are immediately visible to other users), or they can disable it.

The following table shows the different methods of use of the broadcast server (local, network or disabled) and gives the procedure to follow in each case:

 
Method Of Use Procedure
Local (desktop-only) 
  1. Set the Desktop Only broadcast option for the workstation. 
  2. Test broadcast service. 
Over the network 
  1. Install broadcast server files (either at one client or server-side). 
  2. Specify the broadcast server host. 
  3. Set the Network broadcast option on every client workstation. 
  4. Run the broadcast server. 
  5. Test the broadcast service. 
Disabled  Set the Disabled broadcast option for the workstation. 
Full instructions are given in the online help for Repository Management.If you are using this feature over the network, you need to decide whether to run the broadcast server from either a client workstation or from the database server where the repository is installed, and install the broadcast server files accordingly.

Start to Use the Repository Tools

The installation of the new repository instance is now complete. Create any workareas and containers required, grant the access rights to them and inform subordinate users that they can now begin using the repository tools.

If you need help at any point while using a repository tool, choose Help > Help Topics on the tool. If a dialog box is displayed, click its Help button.

Continued Maintenance of the Repository

Tune the Repository

The DBA or the repository owner can perform a number of actions that are designed to maintain or improve repository performance. For full details, look in the Repository Management online help index under "performance".

Set the Database Initialization Parameters

The setting of the database initialization parameters can affect repository performance.

On an Oracle9i database, the initialization parameters are typically managed by the server parameter file (SPFILE). See the Oracle9i Database Administrator's Guide for full details about managing initialization parameters using a server parameter file.

Some Oracle9i databases may manage the initialization parameters by means of an INIT.ORA file (see following paragraphs).

On an Oracle9i database that does not use a server parameter file, the file INIT.ORA at the server contains parameters for configuring the Oracle database at startup. This file can be found at:

database_Oracle_home\ADMIN\dbname\PFILE\INIT.ORA
where database_Oracle_home is the location to which the Oracle database was installed, and dbname is the database name (e.g. the name portion of the name.domain global database name).

If there is more than one Oracle database instance on the server, make sure that you locate the correct file.

The following are the recommended minimum settings.

     compatible = 9.0.0 # for an Oracle9i database
     max_enabled_roles = 30
     sort_area_size = 262144
     sort_area_retained_size = 65536

     hash_area_size = 1048576
     optimizer_index_caching = 50
     optimizer_index_cost_adj = 25
     shared_pool_size = 32000000

     db_block_buffers        # comment out on an Oracle9i database
     db_block_buffers = 2000 # on an Oracle8i database
     open_cursors = 3000
     processes = 100
     db_file_multiblock_read_count=16 # for a 4K Oracle block size
     db_file_multiblock_read_count=32 # for a 2K Oracle block size
     db_file_multiblock_read_count=8  # for a 8K Oracle block size

Note:

For an Oracle 10g database and above these settings can be ignored and instead the default database parameter values can be used. 


These assume that a single repository instance has been installed for up to four concurrent users. If more concurrent users are required, or more than one repository instance is installed, then these parameters will require more tuning. If you are running other systems on the same Oracle database which already require larger settings, then do not make these any smaller.

Carefully consider whether to use or modify the above example settings. It is the responsibility of the DBA to monitor the system and ensure that these parameters are appropriate for the current period of activity.

Retune the INIT.ORA parameters when adding users or switching activities. The Oracle Enterprise Manager monitors and tuning tools can help here.

We recommend that the OPTIMIZER_MODE parameter is set to its default value CHOOSE.

As a guide to sizing your server, the following profiles were used when testing the product internally, and found to be very satisfactory. All testing used dedicated database server machines. Although it is supported to have the repository running on the same machine as the client tools, this is not the way the product is expected to be used outside of a demonstration environment.

A typical configuration for a 5-user installation would be:

A typical configuration for a 300-user installation would be: For a standalone PC with the server and client tools running on it, a memory size of 256 MB is advisable.

Following are some specific modifications you might want to make. On some systems, these changes need to be made in harmony with tuning of the operating system I/O; refer to the specific server documentation for your system. Take care not to increase these parameter values to the point where the SGA will no longer fit in memory.

Set the DB_BLOCK_SIZE Parameter

The default setting of this parameter is operating-system dependent. With Oracle Designer, the recommended Oracle block size is 4096 for a repository which contains mainly repository object data (Designer element data).With Oracle Repository, for a mainly file store repository, the average size of files stored would affect the most appropriate setting, with larger average file sizes requiring larger Oracle block sizes.

Setting the DB_BLOCK_SIZE parameter can be done only before creating a database. You can set this parameter as part of creating a new database by running the Database Configuration Assistant, selecting the Custom option and setting the value on the page for SGA parameter information. To run the Database Configuration Assistant, click the Start button and choose (for an Oracle 9i database) Programs > Oracle - database_Oracle_home > Configuration and Migration Tools > Database Configuration Assistant or (for an Oracle 8i database) Programs > Oracle - database_Oracle_home > Database Administration > Database Configuration Assistant.

Set DB_BLOCK_BUFFERS to 2000 or Higher (Oracle8i databases only)

On an Oracle9i database, remove or comment out this parameter as it is deprecated owing to the Oracle9i dynamic SGA feature.

On an Oracle8i database, if enough memory is available, try a setting of up to 5000 (check its effectiveness using the DB_BLOCK_BUFFER cache hits monitor).

Keeping table data rows cached is effective for speeding up the loading of a large data file or for other operations requiring a lot of API validation. There should be an observable drop in the number of physical disk accesses.

This is the tuning parameter which can most influence the execute and fetch times of SQL statements. Note, however, that any increase in the setting of DB_BLOCK_BUFFERS causes an increase in SGA memory requirement equivalent to (extra * block_size) bytes, where extra is the increase in the DB_BLOCK_BUFFERS setting and block_size is the value of the DB_BLOCK_SIZE parameter in the INIT.ORA file.

Set SHARED_POOL_SIZE to 32 MB or Higher

Increasing the shared pool size reduces reloading and reparsing caused by PL/SQL blocks and SQL being swapped out of cache. With 9i Designer, for a multi-user repository where users are working with different element types, e.g. system modeling and system design, higher values are needed because more (or most) of the API will be required at the same time.

This is the tuning parameter which most affects parsing and loading times. It is most effective if the block or statement is already in memory and ready to run.

Set LOG_BUFFER to 64 KB

Higher values reduce I/O to the redo log file. Try increasing the value from the default if your system performs a lot of long running transactions (e.g. Export/Import), or a large number of smaller ones.

In general, the transaction sizes for the repository tools tend to be small and the transactions infrequent. This parameter probably has little effect in these circumstances, but consider changing it if a large number of users are accessing the repository, as in this case the transaction frequency and sizes could increase dramatically.

Set OPEN_CURSORS to at Least 3000

We recommend setting OPEN_CURSORS to at least 3000.

Use the Default Setting for CURSOR_SHARING

Make sure that the CURSOR_SHARING parameter is set to its default value, EXACT. Changing this value could cause the database connection to be lost.

Set HASH_AREA_SIZE to 1 MB

Setting a large HASH_AREA_SIZE allows a database process to use more memory to do hashing. This reduces the number of times that intermediate results of a hash will have to be stored on disk. However, it can lead to the error:
ORA-3232 : unable to allocate an extent of %s blocks from tablespace %s
To avoid this it is recommended that all tablespaces of type TEMPORARY have their next extents sized to at least 256 KB. To do this, identify the temporary tablespaces with a query such as:
     select tablespace_name, next_extent
     from   dba_tablespaces
     where  contents = 'TEMPORARY'
     and    next_extent < 262144;
For each tablespace returned, issue the command:
     alter tablespace tablespace_name default storage (next 256K);

Use of the LARGE_POOL_SIZE and the MTS

If using the Multi Threaded Server (i.e. MTS_MAX_SERVERS > 0 and MTS_MAX_DISPATCHERS > 0), ensure that the large pool is either large enough to allow all the PL/SQL packages to be compiled, or is not used at all. To do this either set the value of LARGE_POOL_SIZE to 0 (not used) or to a value greater than the 8.1.n default of 614400. A suitable minimum value is 2097152.

If the large pool is used but is too small, the following error will be reported:

ORA-4031: unable to allocate nnnn bytes of shared memory
("large pool","unknown object","session heap","kgiob")

Setting Up the Repository for NLS Operation

If you have a National Language Support (NLS) version of the repository, you can change the display language for the following text: With 9i Designer, if you also use Generator tools, you can change the display language for Generator preference descriptions and their valid value meanings.

The translated text files for the display languages that the repository supports are installed in the directory Oracle_home\REPADM61\NLS if you have an NLS version of the repository.


Note:

If you do not have these translated text files in the \NLS directory, you cannot change the display language. 


To set up the repository for NLS operation, you need to:
  1. Load the language text files (see "Loading language text files" in the online help for the Repository Administration Utility).
  2. Change the display language to the one you want (see "Changing the display language" in the online help for the Repository Administration Utility).

Migrating from a pre-6i Repository

To use a repository from a release of Oracle Designer earlier than 6i, you must migrate the data in it from a live release 2.1.2 or release 6.0 repository (this is the "source repository") into an Oracle9iDS repository that you have already created (this is the "target repository").

Caution:

We recommend using separate database instances for the source and target repositories, to avoid username and synonym conflicts. 


Release 2.1.2 or 6.0 repositories may be migrated directly to 9i.

Release 1.3.2, 2.1 or 2.1.1 repositories must be upgraded to 6.0*, then migrated to 9i.

Pre-1.3.2 repositories must initially be upgraded to release 1.3.2, then to 6.0*, then migrated to 9i.

* An additional CD, supplied with the 6i release, enables you to upgrade these repositories to 6.0 before migrating. Perform the upgrade to 6.0 now before continuing any further.

If you have an existing 6i repository, see "Upgrading a Release 6i or higher Repository".


Note:

During migration from release 2.1.2 or 6.0 to release 9i, a new table is created in the source repository and packages there are recompiled. You will need sufficient free space in your source repository to allow this. 


Checks to Run Before Migration

In release 2.1.2 or 6.0, when a full reconcile is run in the Repository Administration Utility after an Import or Upgrade, sometimes the sequence SDD_EL_SEQ is incorrectly recreated by stage CKUPSEQ. This can cause the following errors to occur during migration to 9i:
    ORA-06502: PL/SQL: numeric or value error: character to number conversion error
    ORA-06512: at "REPOS.GET_IRID", line 21
    ORA-01422: exact fetch returns more than requested number of rows
    ORA-06512: at line 1
    ORA-06512: at line 1
    RME-02124: Failed to execute SQL statement:  INSERT INTO SDD_MUN (...
If your source (i.e. release 2.1.2 or 6.0) repository has application logic, run the following three queries on the source repository before commencing migration to release 9i:
        select max(el_id) from sdd_elements;
        select max(str_id) from sdd_structure_elements;
        select max(al_id)  from ck_application_logic;
If the result from the last query is greater than the result from either of the first two, perform the following actions on the source repository:
        drop sequence SDD_EL_SEQ;

        create sequence SDD_EL_SEQ increment by 1
        nominvalue nomaxvalue nocycle cache 20 noorder
        start with  x + 1;
where x is the highest value from the three query results above, then recompile invalid objects (in the Repository Administration Utility, click the Recreate button, choose Recompile Objects and click Start).

Step 1 - Prepare ("Clean Up") the Source Repository

We strongly recommend that you "clean up" the source repository before migration, by carrying out the following operations. This will save time during the migration and also limit future repository maintenance effort. Use the tools and online help in release 2.1.2 or release 6.0 for these operations. Ensure that nobody is using the repository during any of these operations.
  1. Remove obsolete users.
  2. Remove unused application systems.
  3. Remove obsolete objects and unshare unused objects.
  4. Identify any application systems that receive shares from 'obsolete' application systems and reconnect them to valid application systems.
  5. Remove unused diagrams (e.g. old versions) and diagrams that can be fully derived from the repository content (e.g. module diagrams).
  6. Consolidate all other diagrams.

Step 2 - Optimize the Performance of the Source Repository

We strongly recommend that you optimize the performance of the source repository before migration, by carrying out the following operations. For these operations, use the Repository Administration Utility and associated online help in release 2.1.2 or release 6.0. Ensure that nobody is using the repository during any of these operations.

Note:

These are the normal routine maintenance operations for any repository. If you have recently carried them out, you may not need to do so again. 


  1. Recreate the hash tables.

  2.  
  3. Truncate the temporary tables.

  4.  
  5. Carry out a full user export. If you have grants on objects other than non-repository tables and you wish to retain them, do not use the Repository Administration Utility to carry out the export, but use the following command instead:

  6.  

    Oracle_home\BIN\EXP80.EXE USERID=username/password@database FILE=d:\dump_file LOG=d:\export_logfile


    Caution:

    To provide maximum protection for the data held in your repository, you should now import the dump file and test it before removing anything from the source repository. 


  7. Remove all objects in the source repository (click the Remove All Objects button).

  8.  
  9. Carry out an import of what was exported in step 3. If the export included grants on objects other than non-repository tables, do not use the Repository Administration Utility to carry out the import, but use the following command instead:

  10.  

    Oracle_home\BIN\IMP80.EXE USERID=username/password@database FILE=d:\dump_file LOG=d:\import_logfile IGNORE=Y FULL=Y COMMIT=Y

  11. Carry out a full reconcile.

  12.  
  13. Check the status of objects in the repository. Check for missing, invalid and disabled objects, and correct any problems before continuing.

  14.  
  15. Compute statistics.

Step 3 - Create a Target Repository

If one does not already exist, create a release 9i target repository to accept the data from the release 2.1.2 or 6.0 source repository. See "Installing a New Repository" earlier in this section.

The database that is to host the target repository must have the Distributed Option installed.

We recommend setting the OPEN_CURSORS database initialization parameter to at least 3000 (see Set the Database Initialization Parameters earlier in this chapter). Errors during migration might be cured by increasing the value of the OPEN_CURSORS parameter (see Error Messages for Migration in Appendix C).

Step 4 - Make Backups of the Repositories

Back up the source repository and the target repository. These backups may need to be used if migration fails.

Step 5 - Establish Undo Tablespace or Create Migration Rollback Segment on Source and Target Repositories

Both the source and target repositories need a way of handling undo operations. A source repository for migration will be hosted on an Oracle8i database, while the target repository can be hosted on either Oracle8i or Oracle9i.

Oracle9i Databases Using Automatic Undo

If a database is operating in automatic undo mode (UNDO_MANAGEMENT initialization parameter is set to AUTO), undo operations use a dedicated undo tablespace instead of a rollback segment. In many cases, an undo tablespace is created by default (e.g. with the name UNDOTBS) when the database is created. If so, use that tablespace.

If no undo tablespace exists, proceed as follows:

  1. In SQL*Plus, enter:
  2. create undo tablespace tbs_name datafile ‘filespec’ size nnm;
    where tbs_name is the name of the tablespace, filespec is the complete file specification for the data file, and nn is the tablespace size in megabytes (this size varies depending on the amount of data being migrated).
  3. Set the UNDO_TABLESPACE parameter in the database initialization file (SPFILE or INIT.ORA as appropriate) to point to the new tablespace.

Oracle8i Databases, and Oracle9i Databases using Manual Undo

On both the source repository and on the target repository, create one large non-SYSTEM rollback segment specifically for the migration, and take all others offline.

To see the name and status of all rollback segments:

select segment_name, status from dba_rollback_segs;
To create a new tablespace for the rollback segment:
create tablespace tbs_name datafile ‘filespec’ size nnm;
where tbs_name is the name of the tablespace, filespec is the complete file specification for the data file, and nn is the tablespace size in megabytes (this size varies depending on the amount of data being migrated).

To create the rollback segment and put it online:

create rollback segment rbs_name tablespace tbs_name storage 
(initial 1m next 1m minextents 3 optimal 4m);

alter rollback segment rbs_name online;
where rbs_name is the name of the rollback segment, and tbs_name is the name of the tablespace for the rollback segment.

To take a rollback segment offline, enter the following:

alter rollback segment rbs_name offline;
Note that you cannot take the SYSTEM rollback segment offline.

Step 6 - Ensure That Nobody Is Using the Repositories

Ensure that nobody is using the release 2.1.2 or 6.0 repository from which you intend to migrate data, and that nobody uses either repository during the migration.

Step 7 - Unload and Reload User-Extended Definitions

This step applies if you have created any user-extended definitions and you want to bring them forward into the release 9i repository.

Unload the user-extended definitions from the source repository using the unload option available from the Repository Administration Utility in Oracle Designer 6.0.

To bring forward the user-extended definitions, load this data into a fresh release 9i repository before loading any application system.

Step 8 - Log On to the Machine That Hosts the Oracle Database Where the Target Repository Resides

Log on to the machine that hosts the Oracle database where the release 9i target repository resides.

Step 9 - Ensure That TNS Listener Is Started

You need to have the service named TNS Listener running on the source repository and on the target repository.

See "Ensure That TNS Listener Is Started" earlier.

Step 10 - Check for Correct Repository Owner Privileges

Check that the source repository owner has the following system privileges:
CREATE TABLE
CREATE ANY INDEX
Check that the target repository owner has the following system privileges:
CREATE DATABASE LINK
CREATE TABLE
Grant these privileges if they are not already granted. These privileges must be granted directly to the target repository owner and not via a role.

Step 11 - Check That Subordinate Users in the Source Repository Have the ANALYZE ANY Privilege

In the source repository, check that all subordinate users have the ANALYZE ANY privilege. This is required during migration for a Compute Statistics operation.

Using release 2.1.2 or release 6.0 tools and online help, grant this privilege if it is not already granted.

Step 12 - Migration of Subordinate Users

This step migrates subordinate users from a release 2.1.2 or 6.0 repository to a release 9i repository. The procedure grants the necessary set of system and repository privileges to the subordinate users in the new repository.

The following table shows the SQL scripts used in this step, together with a brief description of each script:
Script Description
CKGENUSR.SQL Located in Oracle_home\REPADM61\UTL directory. This script generates the migration script called MIGRATE_REPOS_USERS.SQL to the working directory.
MIGRATE_REPOS_USERS.SQL When executed, this script creates Oracle database users on the target database (where the release 6i repository resides) with the same usernames and privileges as those from the source database (where the release 2.1.2 or 6.0 repository resides). It also creates a log file called MIGRATE_REPOS_USERS.LOG in the working directory. 

Note: Migrated subordinate users are given the default password "changeme".

CKGENPRV.SQL Located in Oracle_home\REPADM61\UTL directory. This script generates the migration script called MIGRATE_REPOS_PRIVS.SQL to the working directory.
MIGRATE_REPOS_PRIVS.SQL When executed, this script creates repository users with default repository privileges in the release 9i repository. Also creates a log file called MIGRATE_REPOS_PRIVS.LOG in the working directory.


Caution:

Do not make changes to the scripts because such changes will not be supported. If in doubt, contact your Oracle Support Representative for assistance. 


  1. In SQL*Plus, connect to the source (2.1.2/6.0) repository database as the repository owner and run the script Oracle_home\REPADM61\UTL\CKGENUSR.SQL.
  2. Run the script Oracle_home\REPADM61\UTL\CKGENPRV.SQL.
  3. In SQL*Plus, connect to the target (9i) repository database as the user SYS (using the AS SYSDBA clause for an Oracle9i database) and run the MIGRATE_REPOS_USERS.SQL script.

  4.  

    You are prompted for the default tablespace and for the temporary tablespace for all users. After completion, check the log file MIGRATE_REPOS_USERS.LOG and ensure that there are no errors.

  5. In SQL*Plus, connect to the target (9i) repository database as the repository owner and run the MIGRATE_REPOS_PRIVS.SQL script.

  6.  

    After completion, check the log file MIGRATE_REPOS_PRIVS.LOG and ensure that there are no errors.

  7. If there are no errors in any of the log files, click the Maintain Users button in the Repository Administration Utility and check that all users and privileges are as expected, then run a full reconcile on all users (see the online help for the Repository Administration Utility).

Step 13 - Connect the Client, Target Repository and Source Repository machines

The TNSNAMES.ORA file on the client machine must have entries that allow it to see both the source repository and the target repository.

The TNSNAMES.ORA file on the machine containing the target repository must have an entry that allows it to see the source repository.

Step 14 - Connect to the Source Repository

  1. On the machine with the new client software installed, start the Repository Administration Utility.
  2. Click the Migration button (Migration) button on the Repository Administration Utility window to display the Migration Wizard.
  3. In the Username, Password and Connect String boxes, enter the connection details for the source repository owner.
  4. As you type into the Username and Connect String boxes, text is automatically entered into the Workarea Name box. You can change this name manually if you wish. The workarea name will be used to create a new workarea in the target repository to contain the data you are migrating.

  5. Choose and confirm the application systems that you wish to migrate.
      The Migrate A...Repository Instance dialog box is displayed.

Step 15 - Start the Migration

To start the migration:
  1. On the Migrate A...Repository Instance dialog box, click the Start button.
  2. Respond to any message boxes that are displayed.
  3. When you see the message "Operation complete", click OK to return to the Repository Administration Utility window.
For error messages displayed during migration, see Appendix C, "Error Messages".

Caution:

If the migration fails, check the log files for any errors. If these cannot be resolved, contact your Oracle support service. Do not use the new workarea.


Using NLS Features

If you have a National Language Support (NLS) version of the repository and you want to change the display language for certain types of text, continue from "Setting Up the Repository for NLS Operation".

Upgrading a Release 6i or higher Repository

To find out whether your repository can be upgraded with this release:
  1. Start the Repository Administration Utility and connect to the repository.
  2. Check that the Upgrade button is enabled. For repositories earlier than 6i, refer to "Migrating Data from an Existing pre-6i Repository to a New One".
If upgrading from the original Production release (Oracle Designer 6i or Oracle Repository 6i Release 1) only, the order in which you perform the upgrade tasks must be amended. This is necessary because the original Production release is not certified for use with Oracle9i or Oracle 10g and higher, so the required database upgrade must be performed after the repository upgrade.

To upgrade from the Production release, proceed as follows:

If upgrading from any other Oracle Designer or Oracle Repository release, perform the steps in sequence from 1 through 18.

Note:

To upgrade an Oracle Designer repository installed on an Oracle 9i database, the Oracle 9i import/export utilities are required. For details, refer to Step 5 - Install Oracle 9i Import and Export Utilities.

Step 1 - Log On to the Machine That Hosts the Repository

Log on to the machine that hosts the Oracle database where the repository resides.

Step 2 - Check the Settings in the Oracle Initialization Parameter File

See "Ensure Correct Settings for Database Initialization Parameters".

Step 3 - Start or Restart the Oracle Database If Necessary

See "Start or Restart the Oracle Database If Necessary".

Step 4 - Ensure That TNS Listener Is Started

See "Ensure That TNS Listener Is Started".

Step 5 - Back Up the Repository Owner's Account

Back up (export) the whole repository. In the Repository Administration Utility, click the Export button (Export) button and save the backup as a dump file. See the online help for Repository Management for instructions on how to do this.

Step 6 - Upgrade the Server Database If Necessary

The server database should be Oracle9i or higher; see the appropriate Oracle server documentation for upgrade instructions.

Step 7 - Back Up the Server Database (Optional)

See your Oracle database documentation for instructions on backing up the database. This step is necessary only if your database contains important data other than that in the repository, as you can restore the repository from the backup you created in step 5.

Step 8 - Establish Undo Tablespace or Create Rollback Segment for the Upgrade

Oracle9i Databases Using Automatic Undo

If a database is operating in automatic undo mode (UNDO_MANAGEMENT initialization parameter is set to AUTO), undo operations use a dedicated undo tablespace instead of a rollback segment. In many cases, an undo tablespace is created by default (e.g. with the name UNDOTBS) when the database is created. If so, use that tablespace.

If no undo tablespace exists, proceed as follows:

  1. In SQL*Plus, enter:
  2. create undo tablespace tbs_name datafile ‘filespec’ size 10m;
  3. Set the UNDO_TABLESPACE parameter in the database initialization file (SPFILE or INIT.ORA as appropriate) to point to the new tablespace.

Oracle8i Databases, and Oracle9i Databases Using Manual Undo

You do this by creating a rollback segment in the same way as for a first installation. See Establish an Undo Tablespace or a Rollback Segment for the Installation".

Step 9 - Ensure That Temporary Tablespace Is Allocated for the Repository Owner

You should ensure that a suitable tablespace is allocated as the temporary tablespace for the repository owner. This tablespace is used for performing sort operations.

On some servers you can use a predefined tablespace called TEMPORARY_TABLES or TEMPORARY_DATA as the repository owner’s temporary tablespace; on others, you might need to create a tablespace for this purpose.

To see the temporary tablespace for each user, open a SQL*Plus window (if one is not already open), connect as SYSTEM (or as a user with DBA privileges) and enter the following statement:

select username, temporary_tablespace from dba_users;
If you want to change the temporary tablespace for the repository owner, enter a statement of the following form:
alter user repos_owner temporary tablespace temp_tbs_name;
where repos_owner is the username of the repository owner and temp_tbs_name is the name of the temporary tablespace.

Make a note of the tablespace name you will be using. When you have finished, be sure to close the SQL*Plus window.

Step 10 - Log On to Windows at the Client

See "Log On to Windows".

Step 11 - Update the client software

If you have not done so already, update the client software for Oracle Designer or Oracle Designer Repository as appropriate. Make sure that it uses a different Oracle home directory from that used by other Oracle products on the client. However, if other Oracle iDS products are installed, use that Oracle home. For full instructions see the Oracle Developer Suite Installation Guide Release 2.

Step 12 - Drop and recreate the repository owner role and grant system privileges

At the client workstation, start SQL*Plus from Programs > Oracle - iDS_client_home > Application Development > SQL Plus and connect as SYS (using the AS SYSDBA clause for an Oracle database). Drop the role CK_ORACLE_REPOS_OWNER, then recreate the role and grant it to the repository owner. Exit from SQL*Plus.

For more information see "Create and Grant the Role CK_ORACLE_REPOS_OWNER for System Privileges".

Step 13 - Start the Repository Administration Utility

See "Start the Repository Administration Utility". Be sure to connect as the repository owner.

Step 14 - Open the Upgrade Utility

Click the Upgrade button (Upgrade) button on the Repository Administration Utility.

Step 15 - Assign a Rollback Segment

From the Nominate a Rollback Segment dropdown list on the display, select a rollback segment. If you created one in step 8 use that one, otherwise choose one other than SYSTEM.

Step 16 - Start the Upgrade

The upgrade consists of a number of stages. For each stage, a log file is written to the log directory (see Appendix B, "Log Files"). These log files are named stage.LIS, where stage identifies a particular stage. You can examine or monitor the log files while the upgrade is in progress, but do not delete them.

To start the upgrade:

  1. On the Upgrade a Repository Instance dialog box, click the Start button.

  2.  
  3. Reply Yes to the message "Do you wish to proceed?".
If you see the message:
Insufficient database grant privileges to perform operation.
Click the Check Requirements button, proceed as described in "Check Privileges, Tablespaces and Parameters", and then try the upgrade again.

From this point, the upgrade process continues automatically, and normally needs no intervention.

If you need to interrupt the process at any point after the Control Status dialog box is displayed, click the Pause button (Pause) button.

When you see the message "Operation Complete", click OK followed by Cancel to return to the Repository Administration Utility.

If the upgrade appears to complete successfully, examine the log files referred to above to ensure that Oracle errors and warnings were not issued.

If the upgrade fails, examine the log files referred to above, then go to the "Troubleshooting" section.

Tip: You might find it useful to view the log directory files in date order so that you can see which ones were created most recently.

Step 17 - Check for Invalid, Missing or Disabled Repository Objects

It is a good idea, once the upgrade has completed, to check that there are no invalid, missing or disabled repository objects.

To perform this check, do the following in the Repository Administration Utility:

  1. Click View Objects button(View Objects) to open the Object Status Utility.

  2.  
  3. Check for objects with a status of Invalid, Disabled or Missing.
For more information, see the Repository Management help topic about checking the status of repository objects.

Step 18 - Test the Repository

We recommend that you review and test the repository using the repository tools before you allow other users to access the repository.

Using NLS Features

If you have a National Language Support (NLS) version of the repository and you want to change the display language for certain types of text, continue from "Setting Up the Repository for NLS Operation".

Troubleshooting an Installation, Migration or Upgrade

If an installation, migration or upgrade fails for any reason, a message is displayed with an indication of the cause.

Keep the Repository Administration Utility active on the screen if possible, as you might be able to correct the problem and continue. Proceed as follows:

  1. If a "ckrau61" error dialog is displayed:

  2.  
    1. Leave the dialog displayed if possible.
    2. Take the corrective action displayed in the dialog. If you use SQL*Plus to make the correction, be sure to exit from it before proceeding.
    3. Click OK to dismiss the dialog.
    4. Click the Retry button (Retry) button in the Control Status dialog. The operation should now proceed.

    5.  
  3. If the displayed message refers to a log file, examine the log file for error messages. Log files are written to the log directory (see Appendix B, "Log Files").

  4.  
  5. Take any corrective action appropriate to the error message(s) in the log file (see also Appendix C, "Error Messages").

  6.  

    If you can take the corrective action while keeping the Repository Administration Utility still active, do so and continue from step 3.

    If the corrective action is such that you need to close down the Repository Administration Utility, click the Abort button on the message box. Take the corrective action, restart the Repository Administration Utility and restart the installation or upgrade.

  7. If the message box offers the Retry option, click this button after you have completed the corrective action. Clicking Retry causes the system to reattempt the stage of the installation or upgrade that failed, and then continue.

Caution:

Do not use the Continue option, as this attempts to continue the installation or migration without allowing you to take corrective action. 


The remainder of this section gives details of specific cases:

Use Unlimited Extents for Repository Tablespaces

We recommend that the tablespaces created for all repository tables have unlimited extents specified when they are created. This is especially essential for the tablespace nominated as the one to hold temporary repository indexes and tables (at install time), since these tables inherit their sizing from the tablespace definition.

If you have specified a maxextent value (e.g. 121) for this tablespace you may occasionally get errors of the form:

ORA-03235 max # extents (string) reached in table string.string subpartition string
ORA-03236 max # extents (string) reached in index string.string subpartition string
If you see these errors, inform your repository administrator or DBA who will need to alter the tablespace, table and index sizing characteristics as follows.

For tablespaces, use the following command:

alter tablespace tablespace_name default storage ( maxextents unlimited );
Refer to the Administrator's Guide for your database for further information about altering storage characteristics on tablespaces.

For tables and indexes, start the Repository Administration Utility and click the View Objects button. In the Object Status Utility window, select Tables or Indexes, select the name of the table or index, click the right mouse button, choose Quick Edit, choose the Unlimited option button and click OK.

Installation Fails at Stage CKGLBWRK

If a repository installation fails at stage CKGLBWRK with the following message:
RME-02124: Failed to execute SQL statement:... JR_WORKAREA
one possible reason is that the SQL statement to grant the select privilege to the repository owner on SYS.V$PARAMETER has been omitted. This will result in an invalid JR_WORKAREA package and a failure to create the global shared workarea and the system folder.

To recover from this situation:

  1. Start SQL*Plus, connect to the database as SYS (using the AS SYSDBA clause for an Oracle9i database) and enter:
  2. grant select on sys.v_$parameter to repos_owner;
  3. Connect as the repository owner and enter:
  4. truncate table RM$REPOSITORIES;
  5. Enter:
  6. update CK_INSTALLED_OBJECTS set CI_NAME = 'CKVERS' where
    CI_STAGE = 'ABORT';
    commit;
  7. Exit from SQL*Plus.

  8.  
  9. Restart the installation from the point of failure.

'Role CKR_username does not exist' Error on Reinstall After Dropping Repository Owner

If the repository owner database user account is dropped manually for any reason, the repository owner role CKR_username is transferred to the SYS user account. As a result, subsequent reinstallation of the repository fails with the message "Role CKR_username does not exist" on reconciling the subordinate users.

To prevent this problem, do the following before reinstalling the repository:

  1. Start SQL*Plus, connect to the database as SYS (using the AS SYSDBA clause for an Oracle9i database) and enter:
  2. drop role ckr_username;
    where username is the username of the repository owner.
     
  3. Exit from SQL*Plus.

  4.  
  5. Reinstall the repository.

  6.  
  7. Reconcile the subordinate users (in the Repository Administration Utility, click the Recreate button, choose Full Reconcile and click Start).
If the problem has already occurred, do the following:
  1. Close the Repository Administration Utility and any other Oracle Designer Repository tools that are open.

  2.  
  3. Start SQL*Plus, connect to the database as SYS (using the AS SYSDBA clause for an Oracle9i database) and enter:
  4. drop role ckr_username;
    where username is the username of the repository owner.
     
  5. Exit from SQL*Plus.

  6.  
  7. Open the Repository Administration Utility and connect as the repository owner.

  8.  
  9. Reconcile the subordinate users (click the Recreate button, choose Full Reconcile and click Start).

Deinstalling a Repository

The procedure for deinstalling a repository depends on whether the repository was created by means of the SQL scripts or by the manual method (see "Installing a New Repository").

Repository Created by SQL Script Method

To deinstall a repository that was created by the SQL scripts:
  1. At the server, ensure that the parameters are set correctly in the CKPARAMS.TXT file.

  2.  
  3. Make sure that no other users are connected to the repository, and that the repository owner is not connected to the database.

  4.  
  5. Open a Command Prompt window and set the current directory to the one where the scripts are stored:
  6. cd d:\Oracle_home\repadm61\admin
    where Oracle_home is the Oracle home directory where the client tools were installed.
     
  7. From the Command Prompt window, start SQL*Plus:
  8. d:\Oracle_home\bin\sqlplus
  9. At the "Enter username:" prompt, enter the full connect string in the form:
  10. sys/psw@host [as sysdba]
    The AS SYSDBA clause is mandatory for an Oracle9i database.
     
  11. At the SQL> prompt, enter:
  12. @ ckclean
  13. When prompted, enter the password for SYS to start execution of the script.

  14.  
  15. Note the names of the datafiles that need to be manually removed as indicated in the messages.

  16.  
  17. At the message "Cleanup operation complete", exit from SQL*Plus.

  18.  
  19. Delete the datafiles indicated in the messages.

Repository Created by Manual Method

To deinstall a repository that was created manually:
  1. In the Repository Administration Utility, click the Remove Repository button (Remove Repository) button.

  2.  
  3. Answer Yes to the confirmation message.

  4.  
  5. When you see the message "Operation Complete", click OK.

  6.  
  7. Start SQL*Plus.

  8.  
  9. Connect to the database as SYS (for an Oracle9i database, use the AS SYSDBA clause, for example SYS/psw@alias AS SYSDBA).

  10.  
  11. Enter the following command:
  12. drop user repos_owner cascade;
  13. For each repository tablespace, enter the following:
  14. drop tablespace tbs [including contents and datafiles];
    where the portion in square brackets [] is for an Oracle9i database only.
     
  15. For an Oracle8i database, manually delete the datafiles for the repository tablespaces.

Previous
Next
Prev
Next
Oracle logo
Copyright © 2007, Oracle.
All Rights Reserved. 
 
Contents icon
Contents