How To Troubleshoot Messages Generated while Running the Repository Upgrade in Siebel Versions 7.x and 8.

x (Doc ID 477324.1)
Times Viewed 1340 Modified 30-AUG-2007 Type TROUBLESHOOTING

In this Document
Purpose Last Review Date Troubleshooting Details ORA-00001 or SQL0803N or Cannot insert duplicate key row in object... ORA-00955: name is already used by an existing object ORA-01418 or SQL0204N or Cannot drop the index... ORA-01441: column to be modified must be empty to decrease column length ORA-01562 and ORA-01628 ORA-02296 or SQL0407N or Cannot insert the value NULL into column... ORA-25153: Temporary Tablespace is Empty SQL0964C The transaction log for the database is full Invalid column name 'RETURNS' Cannot resolve collation conflict for equal to operation The index entry for row ID was not found in index ID... Unable to verify login name

Applies to:
Area(s):Upgrade Release(s):V7 (Enterprise), V7 (Professional), V7 (MidMarket), V8 (Enterprise), V8 (Professional) Database(s):All Supported Databases App Server OS(s):All Supported Platforms Latest release tested against:V8 (Enterprise) Keywords:ORA-01441, ORA-00001, SQL0803N, ORA-00955, ORA-02296, SQL0407N, SQL1476N, -407, ORA-25153, SQL0964C This document was previously published as Siebel Troubleshooting Steps 21.

Purpose
How To Troubleshoot Messages Generated while Running the Repository Upgrade in Siebel Versions 7.x and 8.x.

Last Review Date

30-Aug-2007

Troubleshooting Details

This guide contains details of some of the common error messages that may be written to the log files generated by the Repository Upgrade (both upgrep and upgphys steps). The upgrade log files should be checked on completion of the Upgrade Wizard to confirm that no unacceptable error messages have been logged. If the Upgrade Wizard ends abnormally then the upgrade log files should be checked to identify the reason for this. Errors found in any of the Upgrade log files should be checked against the errors.rtf / errors.htm files which can be located in the <database server>\<database> directory, for example, dbsrvr\oracle. When checking error messages against this file, it is important that the error is listed as an acceptable error for the log file in which it was logged. For example: ORA-00001 is an acceptable error (for Upgrades run against Oracle databases) when found in seedupg.log, but it is not an acceptable error when found in the ddlseq.log file. If any unacceptable errors are found, the Upgrade will need to be restarted once the cause of the error has been identified and fixed. Instructions on restarting the Upgrade can be found in the Siebel Bookshelf version 7.5.3 > Upgrade Guide for UNIX (or Windows)> Upgrading the Siebel eBusiness Application > Reviewing the Upgrade Log Files > Troubleshooting the Siebel Database Schema Upgrade > Recovering from a Failed Siebel Database Schema Upgrade. The information contained in this guide is intended to provide a starting point for the resolution of any errors detailed below. When further assistance is required, it can be obtained by logging a service request with Oracle Technical Support. In order to optimize the resolution time, attach all the log files written by the Upgrade process to the service request. A summary of the errors documented in this guide can be found below. Further details on any of these errors can be found by clicking on the hyperlink. Note: where appropriate the equivalent error message for all of the supported databases, in other words, DB2, Oracle, and SQL Server, is listed. As the Data Dependent Language (DDL) produced for each database is different, some types of errors may only be seen against a particular database. ORA-00001: unique constraint (SIEBEL.S_ACCNT_SRC_U1) violated The upgrade process is trying to insert a record into a Siebel table that has caused a unique index violation as a record already exists with the same data. ORA-00955: name is already used by an existing object The upgrade process is trying to create an object that already exists in the database. ORA-01418: specified index does not exist The upgrade process is trying to drop an index that the Oracle database is unable to find. ORA-01441: column to be modified must be empty to decrease column length The upgrade process is trying to reduce the length of the column specified but the Oracle database is unable to carry out this command as the column being reduced in size contains data. ORA-01562: failed to extend rollback segment number ## The Oracle database is trying to allocate additional rollback segment space and has been unable to do so. This will normally be accompanied by the ORA-01628 error message. ORA-01628: max # extents (121) reached for rollback segment <rollback_segment_name> This message gives the reason why the Oracle database has not been able to allocate additional rollback segment space. The maximum number of extents has been reached. ORA-02296: cannot enable (SIEBEL.) - null values found The upgrade process is trying to alter the physical definition of the column specified (for example S_PROD_INT.INTEGRATION_ID) to become a not null column. The database cannot process the command as records exist with null values. ORA-25153: Temporary Tablespace is Empty The Oracle database is unable to write to the temporary tablespace. SQL0204N "<index_name>" is an undefined name. SQLSTATE=42704 The upgrade process is trying to drop an index and the DB2 database is not able to find this.

SQL0407N Assignment of a NULL value to a NOT NULL column "<name>" is not allowed. SQLSTATE=23502 The upgrade process is trying to alter the physical definition of the column specified (for example S_PROD_INT.INTEGRATION_ID) to become a not null column. The database cannot process the command as records exist with null values SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because they would produce duplicate rows for a table with a primary key, unique constraint, or unique index. SQLSTATE=23505 The upgrade process is trying to insert a record into a Siebel table that has caused a unique index violation as a record already exists with the same data. SQL0964C The transaction log for the database is full This error message appears when the DB2 transaction log has filled up. This issue can be resolved by increasing the size of the DB2 transaction log (the maximum size supported by DB2 is 32GB in DB2 v7). SQL1476N The current transaction was rolled back because of error "-407". SQLSTATE=40506 The error -407 equates to message SQL0407N and indicates that the upgrade process is trying to alter the physical definition of the column specified (for example S_PROD_INT.INTEGRATION_ID) to become a not null column. The database cannot process the command as records exist with null values. [SQL Server] Cannot insert duplicate key row in object 'S_APP_QUERY' with unique index 'S_APP_QUERY_P1'. The upgrade process is trying to insert a record into a Siebel table that has caused a unique index violation as a record already exists with the same data. [SQL Server] Cannot insert the value NULL into column 'INTEGRATION_ID', table 'f14068.dbo.S_PROD_INT'; column does not allow nulls. UPDATE fails. The upgrade process is trying to alter the physical definition of the column specified (for example S_PROD_INT.INTEGRATION_ID) to become a not null column. The database cannot process the command as records exist with null values. [SQL Server] Invalid column name 'RETURNS'. The SQL Server database has been unable to find the column specified in the database [SQL Server] Cannot resolve collation conflict for equal to operation. This error message has been seen in cases where the conversion of a database from dictionary sort order to binary sort order has not completed successfully. Microsoft Technical Support should be contacted to assist with this. [SQL Server] The index entry for row ID was not found in index ID 62, of table 1330103779, in database 'siebeldev'. This error message will appear when the SQL Server database identifies an issue with an index, for example it has become corrupted. [SQL Server] Cannot drop the index '<index_name>', because it does not exist in the system catalog. The upgrade process is trying to drop an index that the SQL Server database is unable to find. Unable to verify login name <name> The upgrade process is trying to import a repository and is unable to login to the Siebel database using the name specified for the username parameter. This may be because the username and the tableowner name were specified with the same values when the upgrade process was started.

ORA-00001 or SQL0803N or Cannot insert duplicate key row in object...

[MERANT][ODBC Oracle 8 driver][Oracle 8]ORA-00001: unique constraint (SIEBEL.S_ACCNT_SRC_U1) violated or [IBM][CLI Driver][DB2/6000]SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because they would produce duplicate rows for a table with a primary key, unique constraint, or unique index. SQLSTATE=23505 or [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert duplicate key row in object 'S_APP_QUERY' with unique index 'S_APP_QUERY_P1'. Cause The upgrade is trying to insert a record into a Siebel table that has caused a unique index violation as a record already exists with the same data. The SQL statement being executed can be identified from the log file showing the error message, for example, UpgWiz.log may show this error during the execution of RUN_SQL_nnnn in preschm.sql. Diagnostic Steps 1. Check the errors.rtf file (or errors.htm) to confirm whether this is an acceptable error for the upgrade log file this message was written to. 2. Check whether this is caused by a duplicate record on the source table. The following steps can be used as a guide as to how to confirm this: a. Check the SQL statement that has resulted in the error message. This is likely to be in the format: insert into tablea (cola, colb, colc) select colx, coly , colz from tableb where coln = xxxx b. Identify the index reporting the unique index violation from the upgrade log file, for example, S_ACCNT_SRC_U1. c. Check the columns in the above index to identify which columns are being used to determine the duplicate records.

d. Assume in the above example SQL statement shown in 2.a that the columns used by the unique index are tablea.colb and tablea.colc. The data being inserted into these columns comes from tableb.coly and tableb.colz. The SQL statement to run to determine whether duplicate records exist in the source table, tableb, should therefore be as follows: select coly, colz from tableb where coln = xxxx group by coly, colz having count(*) > 1 e. If this SQL statement does not return any rows it means that there is a record on tablea that contains the same user key information as one of the records that is being inserted from tableb. This can be checked by running the following SQL statement:

select a.row_id, b.row_id from tablea a, tableb b where a.colb = b.coly and a.colc = b.colz 3. If the unique index violation occurs on a *_P1 index, verify that the upgrade has not been run for a second time by mistake. This can be done by checking the log files in the Siebel Server\log directory for versions 7.0.x > 7.5.2 and Siebel Server\log\<process_name> for version 7.5.3 and higher (where process_name is the name of the upgrade process being run, for example, upgphys_prod_601). It may be necessary to check the Siebel Server\logarchive directories in case the log files have already been archived. 4. If the unique index violation occurs on a *_P1 index and the upgrade has not been run twice, this means that there may be records in the Siebel database in two different tables with the same value for ROW_ID, and one of the records is being inserted into a table that already contains the other record. Under normal circumstances this should not be possible as the value for ROW_ID should be unique across the entire database and not just unique within a table. Oracle Technical Support should be contacted for assistance. Solution 1. If the error message is documented in errors.rtf (or errors.htm) as an acceptable error for the log file it is appearing in then no further action is required. Note: the errors.rtf file does not show every table that will get this error the important thing to check is whether the message is listed as an acceptable error for the log file it has been written to. 2. If the error is caused by data issues, then the data will need to be corrected before the Upgrade process can be restarted. Contact Oracle Technical Support for assistance with this behavior. 3. Oracle Technical Support should be contacted for assistance with any unique index violation on a *_P1 index. 4. If this is caused by a data issue, then this can be resolved by forcing a new ROW_ID value to be allocated for the records that contain the same values in this column. To do this, new records should be created and the original records merged into these new records. For other causes Oracle Technical Support will advise on a resolution.

ORA-00955: name is already used by an existing object

[MERANT][ODBC Oracle 8 driver][Oracle 8]ORA-00955: name is already used by an existing object Cause The upgrade process is trying to create a database object that already exists. Diagnostic Steps 1. Check the errors.rtf file (or errors.htm) to confirm whether this is an acceptable error for the upgrade log file this message was written to.

2. Check that the database configuration has been defined in accordance with the information
specified in the Siebel Server Installation Guide for general advice on how to configure the database. Check the Siebel Server Upgrade Guide for advice on upgrade specific configuration. NOTE: The values for the Oracle configuration parameters may need to be increased for the Upgrade process. In particular, check that sufficient space has been allocated for the System Global Area (SGA) parameters (shared pool and buffer cache).

3. Review Document 476988.1 to ensure that the correct codepage has been specified.
Solution 1. If the error message is documented in errors.rtf (or errors.htm) as an acceptable error for the log file it appears in, then no further action is required. Note: The errors.rtf file does not show every table that may get an ORA-00955 error the important thing to check is whether ORA-00955 is listed as an acceptable error for the log file it has been written to. 2. Ensure that the database configuration has sufficient space allocated to support the Upgrade process.

3. Follow the instructions in Document 476988.1 to ensure that the correct codepage is being used.

ORA-01418 or SQL0204N or Cannot drop the index...

S0012: [MERANT][ODBC Oracle 8 driver][Oracle 8]ORA-01418: specified index does not exist drop index S_ASGN_RULE_F1 ; writeExecDDL error (UTLOdbcExecDirectDDL pDDLSql). writeExecDDL error (pOperCallback UTLDbDdlOperIndDrop). Error in MainFunction (UTLDbDdlDbMerge). Error in Main function... or [IBM][CLI Driver][DB2/NT]SQL0204N "<index_name>" is an undefined name. SQLSTATE=42704 or [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot drop the index '<index_name>', because it does not exist in the system catalog. Cause The upgrade process is trying to drop an index, but the database is unable to find it. Diagnostic Steps 1. Check the errors.rtf file (or errors.htm) to confirm whether this is an acceptable error for the upgrade log file this message was written to. 2. Check that the index has been created with the correct table owner details as this message has been seen in cases where indexes have been created with a different table owner than the Siebel table owner, for example, SYSTEM database user rather than SIEBEL database user.

3. If using a SQL Server database and performing an upgrade to Siebel 2000 then Document
475431.1 should be reviewed. 4. For DB2 databases, check whether the SQL0204N message is referencing an index and appears after a DROP INDEX command. Solution 1. If the error message is documented in errors.rtf (or errors.htm) as an acceptable error for the log file it is appearing in, then no further action is required. Note: The errors.rtf file does not show every table that may get this error the important thing to check is whether the error message is listed as an acceptable error for the log file it has been written to. 2. The indexes will need to be recreated using the correct table owner details before the Upgrade process can be restarted.

3. Follow the instructions in Document 475431.1 before restarting the Upgrade using the
instructions in the Siebel Bookshelf version 6.0 > Upgrade Guide > Recovering from a Failed Repository Upgrade. 4. If the object in the message is not an index and does not appear as an acceptable error message for the upgrade log file, then Oracle Technical Support should be contacted for assistance.

ORA-01441: column to be modified must be empty to decrease column length

Modifying column LAYOUT alter table S_WF_PROC_FLOW modify LAYOUT varchar2(1999) [DataDirect][ODBC Oracle driver][Oracle]ORA-01441: column to be modified must be empty to decrease column length Cause The upgrade is trying to reduce the length of the column specified using the following command: alter table S_WF_PROC_FLOW modify LAYOUT varchar2(1999) Oracle database is unable to carry out this command when the column being reduced in size is not empty. These messages occur for both the S_WF_STEP and S_WF_PROC_FLOW tables as the LAYOUT column is being modified from varchar(2000) to varchar(1999). Diagnostic Steps Identify the tables and columns affected by this behavior. Although this is most commonly seen for the two tables mentioned above it can occur for other tables and columns. Solution The LAYOUT column in S_WF_STEP and S_WF_PROC_FLOW tables will need to be reduced in size manually by the Database Administrator (DBA) from varchar(2000) in the pre-Siebel version 7.5

repository to varchar(1999) in the Siebel version 7.5 or higher repository. This work can be done either before continuing with the Upgrade process or on completion of the Upgrade process. Note: If this work is done on completion of the Upgrade process then similar errors are likely to be encountered during Upgphys. Before taking any action, the data in the LAYOUT column should be examined to ensure that there are no records containing more than 1999 bytes of data. This can be done by using the following commands: select max(length (LAYOUT)) from S_WF_STEP; select max(length (LAYOUT)) from S_WF_PROC_FLOW; An example of a script that can be used to decrease the size of the LAYOUT column in both tables mentioned above is as follows this work should be carried out by the DBA: ALTER TABLE S_WF_STEP ADD LAYOUT_TEMP VARCHAR2(1999); UPDATE S_WF_STEP SET LAYOUT_TEMP = LAYOUT; COMMIT; ALTER TABLE S_WF_STEP DROP COLUMN LAYOUT; ALTER TABLE S_WF_STEP ADD LAYOUT VARCHAR2(1999); UPDATE S_WF_STEP SET LAYOUT = LAYOUT_TEMP; COMMIT; ALTER TABLE S_WF_STEP DROP COLUMN LAYOUT_TEMP; COMMIT; ALTER TABLE S_WF_PROC_FLOW ADD LAYOUT_TEMP VARCHAR2(1999); UPDATE S_WF_PROC_FLOW SET LAYOUT_TEMP = LAYOUT; COMMIT; ALTER TABLE S_WF_PROC_FLOW DROP COLUMN LAYOUT; ALTER TABLE S_WF_PROC_FLOW ADD LAYOUT VARCHAR2(1999); UPDATE S_WF_PROC_FLOW SET LAYOUT = LAYOUT_TEMP; COMMIT; ALTER TABLE S_WF_PROC_FLOW DROP COLUMN LAYOUT_TEMP; COMMIT; Change Requests 12-DRARVK has been logged to address this product defect and has been fixed in Siebel version 7.7.

ORA-01562 and ORA-01628

ORA-01562: failed to extend rollback segment number ## ORA-01628: max # extents (121) reached for rollback segment <rollback_segment_name> Cause The Oracle Database is trying to allocate additional space for the rollback segment described in the error message and has been unable to do so because of the reason specified in the accompanying message. In this case it is because the maximum extents have been reached. Diagnostic Steps

Check that the size of the rollback segments has been set in accordance with the information provided in both the Siebel Upgrade guide and the Siebel Installation guide. For the Siebel Upgrade process it is important to verify that only one large rollback segment is on-line. Solution All small rollback segments should be taken offline and a single large rollback segment should be put online. If there is sufficient space allocated for the rollback segment users may wish to set the maximum extents on the table space to unlimited.

ORA-02296 or SQL0407N or Cannot insert the value NULL into column...

[MERANT][ODBC Oracle 8 driver][Oracle 8]ORA-02296: cannot enable (SIEBEL.) - null values found or [IBM][CLI Driver][DB2/SUN]SQL1476N The current transaction was rolled back because of error "-407". SQLSTATE=40506 [IBM][CLI Driver][DB2/SUN]SQL0407N Assignment of a NULL value to a NOT NULL column "<name>" is not allowed. SQLSTATE=23502 or [SQL Server]Cannot insert the value NULL into column 'INTEGRATION_ID', table 'f14068.dbo.S_PROD_INT'; column does not allow nulls. UPDATE fails. Cause The Upgrade process is trying to alter the physical definition of the column specified (for example S_PROD_INT.INTEGRATION_ID) to become a not null column. The command being issued to the database will be similar to the following. Note: The actual syntax will vary from one database to another: alter table S_PROD_INT modify INTEGRATION_ID not null The database is not able to process this command as the column specified, for example S_PROD_INT.INTEGRATION_ID contains null values in at least one of the records. Diagnostic Steps These errors are not acceptable errors, and the data must be fixed to enable the upgrade process to complete successfully. To do this it is necessary to identify all the records that have null values in the table/column shown in the error message. This can be done using the following select statement: SELECT ROW_ID FROM S_PROD_INT WHERE INTEGRATION_ID IS NULL; If this error occurs for a column that did not exist in the prior version of the Siebel application, then contact Oracle Technical Support for assistance.

Solution It will be necessary to populate values into the table/column shown in the error message for all records returned by the above SQL statement. The database will first need to be restored from backup in order to modify the data. Modification of the data can be done either via the User Interface or by running an EIM task. The values for ROW_ID returned will assist in identifying the records that will need to be updated. Once the data has been updated, the Upgrade process can be re-run. Oracle Technical Support can be contacted for further assistance. Change Request 12-CJRQW1 has been logged to address this product defect and is not applicable to Siebel version 8.0.

ORA-25153: Temporary Tablespace is Empty

[DataDirect][ODBC Oracle driver][Oracle]ORA-25153: Temporary Tablespace is Empty Cause Oracle Database is not able to write to the temporary tablespace. Diagnostic Steps Check whether the datafile for the temporary tablespace has been associated with the tablespace itself. The Oracle Meta link web site should be consulted for further information about why this error may have occurred along with ways to resolve this. Solution The datafile for the temporary tablespace should be associated with the tablespace itself. This can be done using the command listed below. The command should be executed by the DBA after ensuring the values below reflect the names used in the Siebel environment: alter tablespace TEMP add TEMPFILE The Oracle documentation should be referred to for further details on the correct use of this command. Once this issue has been resolved the Upgrade process can be restarted.

SQL0964C The transaction log for the database is full

SQL0964C The transaction log for the database is full Cause This error message appears when the DB2 transaction log has filled up. This issue can be resolved by increasing the size of the DB2 transaction log. (The maximum size supported by DB2 is 32GB in DB2 v7). Diagnostic Steps

1. Check whether the DB2 transaction log size can be increased. 2. Check whether there are any other concurrent applications running alongside the Upgrade process. 3. Check that enough disk space is available. Solution 1. Increase the size of the DB2 transaction log by adding further primary/secondary log files or increasing the size of the log files. To activate these changes, all applications must be disconnected followed by a stop and start of the database. 2. If concurrent applications were running alongside the Upgrade process, these should be stopped before restarting the Upgrade process. 3. Allocate some additional disk space to enable the Upgrade process to complete. If the above suggestions do not help to resolve this then it may be necessary to break the SQL statement into a number of smaller statements. Oracle Technical Support should be contacted for assistance with this.

Invalid column name 'RETURNS'

[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name 'RETURNS'. Cause This error message is caused when the SQL Server database is not able to find a column name referenced in a SQL statement, for example: update S_STORE_COND set NUM_RETURNS = RETURNS where NUM_RETURNS is null and RETURNS is not null Diagnostic Steps 1. Check whether this message is listed as an acceptable error in the errors.rtf / errors.htm files (for the upgrade log file containing the error). 2. Check whether the Siebel database is owned by dbo which should be the default schema owner for the Siebel database. When a database is created in MS SQL Server, the dbo user is created by default. This would normally be used as the database/table owner for the Siebel database. The grantusr.sql script gives the LOGIN name of SIEBEL to this default dbo user. If the tableowner user is created manually then it is possible that the Siebel database will be owned by SIEBEL rather than dbo. Solution

1. If this is an acceptable error then no further action is required, and the upgrade process can continue. 2. To resolve this it will be necessary to drop the database and recreate it. The users should be created using the grantusr.sql script to ensure that the Siebel database is owned by the dbo user. Once this has been done the upgrade process can be re-run.

Cannot resolve collation conflict for equal to operation

[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot resolve collation conflict for equal to operation. Cause This error message has been seen in cases where the conversion of a database from dictionary sort order to binary sort order has not completed successfully. Diagnostic Steps Microsoft Technical Support will need to be contacted for assistance with this. Solution Microsoft Technical Support will need to advise on the solution to this.

The index entry for row ID was not found in index ID...
[Microsoft][ODBC SQL Server Driver][SQL Server]The index entry for row ID was not found in index ID 62, of table 1330103779, in database 'siebeldev'. Cause This error message will appear when the SQL Server database identifies an issue with an index, for example, it has become corrupted. Diagnostic Steps The Microsoft SQL Server DBCC utility can be used to confirm the table and index mentioned in the error message. Microsoft Technical Support should be contacted for assistance with this process. Solution The index can be repaired using the Microsoft SQL Server DBCC CHECKTABLE utility specifying the repair option. Any issues with this should be referred to Microsoft Technical Support for assistance.

Unable to verify login name <name>

Trace Trace 3 Cause

2002-06-27 12:24:48

Unable to verify login name siebel.

This error message will normally occur during the repository import stage of the Upgrade process. The cause is normally incorrect values being specified for the username field. This may be because the username and tableowner names have been given the same value, in other words, Siebel and Siebel. Diagnostic Steps Verify the values entered for the username and the tableowner are correct. The value entered for username should be a Siebel user defined with Siebel Administrator responsibilities (normally this will be SADMIN). This is because when the repository import is run, the utility will try to login to Siebel database using this value. Solution Specify a valid Siebel userid with Siebel Administrator responsibilities and restart the Upgrade process.