Applies to:
Siebel System Software - Version: 7.7.1 [18306] and later [Release: V7 and later ]Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.1 [18306]
Database: Oracle 9.2.0.6
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-2760869491.
Symptoms
Customer reported the following:One of our Siebel Object Manager on our QA server failed and is not coming up now. Along with the Object manager we have Assignment manager and EIM components running on this server. All the other components apart from Object managers are running fine.
We have tried restarting this server and complete environment after disabling and enabling the Siebel object manager for this server but it failed to come up regardless.
siebmtsh and siebsvc processes are coming up after restarting , below is the output of prstat cmd.
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
19742 siebel77 305M 191M sleep 58 0 0:00.22 0.0% siebmtsh/10
19706 siebel77 226M 223M sleep 58 0 0:00.13 0.0% siebsvc/6
19743 siebel77 146M 37M sleep 59 0 0:00.00 0.0% siebmtsh/16
22158 siebel77 143M 26M sleep 58 0 0:00.00 0.0% siebsess/4
19735 siebel77 131M 20M sleep 59 0 0:00.00 0.0% siebmtsh/9
19736 siebel77 127M 18M sleep 58 0 0:00.00 0.0% siebmtsh/8
19741 siebel77 124M 16M sleep 58 0 0:00.00 0.0% siebproc/4
20981 root 71M 43M sleep 29 10 0:00.00 0.0% vxsald/15
20698 root 64M 36M sleep 29 10 0:00.03 0.0% vxsvc/21
3940 root 48M 27M sleep 58 0 0:00.00 0.0% java/22
829 root 30M 28M sleep 59 0 0:00.00 0.0% dsmc/6
916 pat340 16M 14M sleep 28 10 12:03.05 0.1% PatrolAgent/4
21026 root 14M 4328K sleep 28 10 0:00.00 0.0% vxsragt/4
13311 root 12M 11M sleep 52 0 30:05.09 0.6% PatrolAgent/1
20 root 10M 8680K sleep 58 0 0:10.19 0.0% vxconfigd/1
1442 pat340 9240K 6688K sleep 29 10 0:44.27 0.0% dcm/1
5313 root 7800K 5528K sleep 59 0 0:00.00 0.0% dsmc/4
1452 pat340 6888K 4872K sleep 28 10 3:27.24 0.0% bgscollect/1
5277 root 6592K 4680K sleep 58 0 0:00.11 0.0% mstragent/6
5275 root 6096K 4136K sleep 59 0 0:00.06 0.0% mstragent/4
390 root ...
Solution
For the benefit of other readers:
After a restart of the Siebel Server the customer was unable to launch any Siebel Application e.g. Siebel Sales (SSEObjMgr_enu). The start_server.sh script would execute without error. On further investigation it was found that no log files were created for the SSEObjMgr_enu component. The enterprise log file shows many processes exiting on startup e.g.
ServerLog ProcessExit 1 0 2006-01-06 02:48:16 SSEObjMgrRS_enu 35879 SBL-GEN-00001 Process exited with error - Error code SBL-GEN-00001
ServerLog ProcessExit 1 0 2006-01-06 02:48:16 SCCObjMgr_enu 35880 SBL-GEN-00001 Process exited with error - Error code SBL-GEN-00001
ServerLog ProcessCreate 1 0 2006-01-06 02:48:16 Created multithreaded server process (OS pid = 835) for Communications Inbound Processor with task id 35887
ServerLog ProcessExit 1 0 2006-01-06 02:48:16 EAIObjMgr_enu 35881 SBL-GEN-00001 Process exited with error - Error code SBL-GEN-00001
ServerLog ProcessExit 1 0 2006-01-06 02:48:17 SSEObjMgr_enu 35876 SBL-GEN-00001 Process exited with error - Error code SBL-GEN-00001
To troubleshoot the behavior the customer was asked to run truss on the server startup i.e.
truss -aefd -o truss-startup.txt start_server all
An examination of the truss output showed that there was a problem with the Mainwin regss process (pid=1186) at startup. The truss output shows:
1186: 58.1163 open64("/app/siebel/siebel7/siebsrvr/mw/.mw/core_data//gpsapp115
/.mw/hklm_sunos5.bin.gpsapp115.1186_1", O_RDONLY) = 16
1186: 58.1165 fstat64(16, 0xFFBECF68) = 0
1186: 58.1166 fcntl(15, F_FREESP64, 0xFFBECEB8) = 0
1186: 58.1168 read(16, " R E G 3\0\0\002\0\0\018".., 32768) = 32768
1186: 58.1169 close(16) = 0
The Mainwin registry file hklm_sunos5.bin.gpsapp115.1186_1 was truncated, must like due to a disk space problem and only 32768 bytes of the file were present. This in turn caused the regss process to exit. The Mainwin daemons regss, watchdog and mwrpcss process must all be running in order for the Siebel Server to startup without error.
The workaround was as follows:
1. cd $SIEBEL_ROOT/mw/.mw/core_data/<server-name>/.mw/ , where <server-name> is the name of your siebel application server instance.
2. Move all occurrences of files starting with prefix hklm_sunos5.bin to a backup directory
When the Siebel server is restarted the Mainwin processes also startup and a new registry file is created.
Applies to:
Siebel Financial Services CRM - Version: 7.8.2.14 SIA[19251] and later [Release: V7 and later ]Information in this document applies to any platform.
Symptoms
A new siebel applications server environment version 7.8.2.14 was setup. The application server was up and running, however after enabling/disabling components for the specific servers and tried to restart afterward it was noticed that the AOM are not starting up, although the application server is up and running.
More in detail:
There are 3x application servers and 2 of those are load balanced for object manager components i.e. FinsObjMgr_enu.
These two servers are SS_PRD2 and SS_PRD3.
Application server SS_PRD2 is up and running.
Application server SS_PRD3 was also up and running, however after doing some additional configuration in terms of enabling components, many components fail to start after server startup.
Cause
Steps as per article Siebel Server threads fail when using start_server all (Doc ID 524537.1) were already executed and this didn't help to resolve the issue.Likely cause is some corruption somewhere else.
Steps in article Siebel Server threads fail when using start_server all (Doc ID 524537.1) should have helped to resolve the issue. Because it didn't there could be corruption in mainwin part.
Solution
1> Open a new connection / session via telnet of ssh to the system
2> source the siebenv.sh environment variables by navigating to <SIEBEL_ROOT>/siebsrvr and execute:
. ./siebenv.sh
3> Stop the siebel server service and confirm with list_servers command and ps -elf command to ensure all siebel related processes are terminated.
4> navigated to the $MWHOME/bin directory
5> executed the "mwadm status" command and confirmed mainwin was not running
If they are running execute "mwadm stop"
and again executed the "mwadm status" command and confirmed mainwin was not running
8> rename the folder $MWHOME/.mw (please take attention to the "." in ".mw")
9> navigated to $MWHOME/bin directory
10> executed the "mwadm start" command
11> executed the "mwadm status" command and confirmed mainwin was successfully started.
12> start the siebel server using the command "start_server all"
References
NOTE:524537.1 - Siebel Server threads fail when using start_server allNOTE:476830.1 - How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0
NOTE:473791.1 - What Are These Third Party MainWin MSC Server Processes: watchdog, regss and mwrpcss?
Applies to:
Siebel System Software - Version 7.7.2 SIA [18325] and laterz*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325] Com/Med
Database: Oracle 9.2.0.5
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: IBM AIX 5L 5.2
This document was previously published as Siebel SR 38-3278545101.
Symptoms
SBL-GEN-00001Hi there,
We are having a major issue now in production one of the siebel servers in the enterprise was mistakenly started up with other user and afterwards it was recognized and the services were stopped and all the cleansync procedures were followed on support web and started with Siebel service owner user even then the server is starting up and few of the component like eCommunciation_enu the one which is used is coming unavailable. This server is so critical that we are having all workflow process running on it and they interact with middleware. As we are not having this system up all the business related activities such as activations, sales order submission are getting impacted. Please kindly get back to us as soon as possible.
Thanks & Regards,
Cause
Configuration/ SetupSolution
Message 1
For benefit of other readers, customer encountered issues when starting up Siebel server. The components would start and then immediately stop.Resolution
1) It was verified if mainwin processes namely regss, mwrpcss and watchdog were running or not. They were not running.
2) mTried to manually start the mainwin processes by issuing the following command:
mwadm start
It exited with error "Core services not started"
3) This confirmed that the Siebel components were going down with the SBL-GEN-00001 error after the services were started as they were not able to connect to mainwin.
4) Customer had mistakenly tried to start the siebel services earlier as a non-siebel service owner account and after which start having problems with this particular Siebel server. It was suspected that the mainwin related files may not have got cleaned up properly as it was attempted to startup siebel server as a incorrect user.
5) Navigate to $SIEBEL_SERVER/mw directory and rename the .mw directory underneath the mw directory.
6) Mmanually tried to start the mainwin processes by executing :
mwadm start
This time it started successfully and noted all the three mainwin processes running.
7) Sarted the siebel server and all the components came up successfully.
Applies to:
Siebel System Software - Version: 7.5.3 [16157] and later [Release: V7 and later ]IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157] ESN
Database: Oracle 9.2.0.4
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1
This document was previously published as Siebel SR 38-1351070553.
Symptoms
SBL-GEN-00001We are upgrading from 7.0.4 to 7.5.3We are running upgrep and there is an issue that aborts the process:
Trace Trace 3 2004-06-17 04:37:09 Modifying index S_SRC_GOAL_U1 ...
SQLError Statement 0 2004-06-17 04:37:13 create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging
tablespace SIEBELI
GenericLog GenericError 1 2004-06-17 04:37:13 [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel
query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Trace Trace 3 2004-06-17 04:37:13
HY000: [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Trace Trace 3 2004-06-17 04:37:13 Dropping index with the same column signature and retrying...
Trace Trace 3 2004-06-17 04:37:13 create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging
tablespace SIEBELI
Trace Trace 3 2004-06-17 04:37:13
;
Trace Trace 3 2004-06-17 04:37:13 writeExecDDL error (pOperCallback UTLDbDdlOperIndModify).
Trace Trace 3 2004-06-17 04:37:15 Error in MainFunction (UTLDbDdlDbMerge).
Trace Trace 3 2004-06-17 04:37:15 Error in Main function...
GenericLog GenericError 1 2004-06-17 04:37:15 (logapi.cpp 13(167) err=1 sys=0) SBL-GEN-00001: (logapi.cpp 13: 167) error cod
e = 1, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
--------------
We understand that this is a problem due to Vanilla repository definition were the sentence
create unique index S_SRC_GOAL_U1 on SIEBEL.S_SRC_GOAL (SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging tablespace SIEBELI;
Cause
Change Request 12-MU33JSolution
------------
During upgrade from 7.0.4 to 7.5.3, the following error causes upgrade to abort:
Trace Trace 3 2004-06-17 04:37:09 Modifying index S_SRC_GOAL_U1 ...
SQLError Statement 0 2004-06-17 04:37:13 create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging
tablespace SIEBELI
GenericLog GenericError 1 2004-06-17 04:37:13 [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel
query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Trace Trace 3 2004-06-17 04:37:13
HY000: [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Resolution:
----------
* In the version 7.0.4, the index S_SRC_GOAL_U1 indexes (SRC_ID, NAME, CONFLICT_ID) while in version 7.5.3, the index S_SRC_GOAL_U1 indexes (SRC_ID, GOAL_CD, CONFLICT_ID)
* In the version 7.5.3, this table is being used in a Standard installation by BC "Marketing Plan Goals"
* In the version 7.0.4 this table is NOT being used. So, in this case, customer had customizations using this table. When customer upgraded, this issue occurred because it is not expected that this table contain rows.
* you have rows that differs only by the value of NAME column being different (SRC_ID, NAME, CONFLICT_ID), which is fine for the unique key in 7.0.4. During upgrade, the GOAL_CD is populated with null, and NAME is not part of the unique key, and hence violating the unique key and giving the errors that they saw.
After consulting internal resources, this is what you have to perform:
1) Prior to upgrade, the customer uses the Table Wizard in Tools to create a new custom CX_ table (CX is the default prefix when using the Table Wizard). Customer can name the table based on the data stored in the old S_SRC_GOAL.
2) Prior to upgrade, the customer DBA manually renames the S_SRC_GOAL table to a temporary name (such as TEMP_SRC_GOAL)
3) Prior to upgrade, the customer DBA drops all indexes from the table S_SRC_GOAL.
4) Customer runs the Production upgrade (which recreates the S_SRC_GOAL table
and creates their new CX_ replacement table)
5) After the upgrade, the customer DBA runs a SQL statement to copy the rows from TEMP_SRC_GOAL to their CX_ replacement table
This way, you should not have issues on this table during the upgrade. The objects that used the old S_SRC_GOAL will now use the new CX table.
Change Request 12-MU33J1 was logged to address this issue. Please, use the workaround above to perform the upgrade.
Thank you.
Applies to:
Siebel System Software - Version: 7.7.2 [18325] and later [Release: V7 and later ]IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325]
Database: IBM DB2 8.1 FixPack 8
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2
This document was previously published as Siebel SR 38-3273435471.
Symptoms
SBL-GEN-00001We are unable to get our internal siebel server and custom object managers up and running. The gateway starts fine and our external servers start fine.We cannot login to internal urls, however we can login to external urls.
I have attached a tar file of all our logs on the internal siebel server
This error is occurring on our test system that mirrors production.
We have recycled our database and rebooted the aix box that runs our gateway and internal siebel server.
Thanks
Cause
Configuration/ SetupSolution
Message 1
For the benefit of other readers:The /tmp filesystem had become full immediately prior to the behavior occurring.
This caused a corruption of the MainWin Registry, even though space was since freed up in /tmp.
Siebel 7.7 MainWin uses file $MWHOME/.mw/core_data/<hostname>/.mw/hklm_<OS>.bin, instead of the $SIEBEL_ROOT/mw/system/registry.bin file, that was used in Siebel 7.5.
If this file is removed, it is copied from $SIEBEL_ROOT/mw/system/hklm.bin.
The following steps resolved the behavior:
- stop your Siebel Server
- run siebenv.sh shell script from siebsrvr directory
- go to $MWHOME/bin
- execute “mwadm status” to confirm that MainWin is not running
- run “ps -ef | grep regss”, “ps -ef | grep mwrpcss” and “ps -ef | grep watchdog” to confirm that no MainWin-related processes are running
- navigate to $MWHOME/.mw/core_data/p2st77gs/.mw directory and rename file hklm_<OS>.bin
- go to $MWHOME/bin directory
- run “mwadm start”
- run “mwadm status” command to confirm that MainWin was successfully started
- start your Siebel Server
Applies to:
Siebel System Software - Version: 7.7.2.2 SIA [18356] and later [Release: V7 and later ]z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356] ESN Engy/Oil
Database: Oracle 9i
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: HP-UX 11i
This document was previously published as Siebel SR 38-2513843501.
Symptoms
SBL-GEN-00001Hi support,- We have Siebel 7.7.1 environment and we've tried to do an export of the repository for all languages but an error has ocurred.
command line with parameter ALL:
D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ALL
Two files attachments: repimexp_7.7.1_ALL.log, repimexp_7.7.1_ALL2.log
- When we do the export for one language (in this case ESN) procedure with Siebel 7.7.1 environment, it works fine.
command line with parameter ESN:
D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ESN
Two files attachments: repimexp_7.7.1_ESN.log, repimexp_7.7.1_ESN2.log
- But the same sentence for all languages with Siebel 7.7.2.2 environment works correctly:
One file attachments: repimexp_7.7.2.2_ALL.log
Thanks
Cause
Change Request 12-18GQP3HSolution
To export ALL languages in the repository, following syntax can be used:
D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p ***** /d siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ALL
/w - parameter specifies to export either ALL or individual language such as ENU, FRA, ESN etc.
When customer tried to export ALL languages, following errors are encountered and reported in exprep.log file:
GenericLog GenericError 1 0 2005-11-04 17:19:01 Unable to create process instance.
SQLDBUtilityLog SQLDBUtilityLog 3 0 2005-11-04 17:19:01 Unable to start common api.
SQLDBUtilityLog SQLDBUtilityLog 3 0 2005-11-04 17:19:01 Unable to start common api.
SQLDBUtilityLog SQLDBUtilityLog 3 0 2005-11-04 17:19:01 Error in initiate function..
SQLDBUtilityLog SQLDBUtilityLog 3 0 2005-11-04 17:19:01 Elapsed time: 3 sec.
GenericLog GenericError 1 0 2005-11-04 17:19:01 (logapi.cpp (167) err=1 sys=126) SBL-GEN-00001: (logapi.cpp: 167) error code = 1, system error = 126, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
Change Request 12-18GQP3H is raised regarding export of repository for all languages does not work in 7.7.1 release.
The same syntax worked fine in Siebel 7.7.2 release. Also an individual language can be exported in 7.7.1 successfully using /w parameter e.g. /w FRA or /w ESN and so on.
Applies to:
Siebel CRM - Version: 8.1.1.3 SIA[21219] and later [Release: V8 and later ]Information in this document applies to any platform.
Symptoms
Repository migration fails when performing Repository Import. The imprep.log has below error:
2011-03-07 12:08:57 /app/sba_81/siebsrvr/bin/repimexp /a I /g ALL /u SIEBEL /p ***** /c SBA_81_DSN /d SIEBEL /r "SS Temp Siebel Repository" /f /app/sba_81/dbsrvr/common/migrep.dat /l /app/sba_81/siebsrvr/log/dev2prod/output/imprep.log /M y
2011-03-07 12:08:57
2011-03-07 12:08:57 Connecting to the database...
2011-03-07 12:09:00 Connected.
2011-03-07 12:09:00 Starting common api.
2011-03-07 12:09:00 SQLstyle is 'Oracle'
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 Unable to verify login name SIEBEL.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Error in initiate function..
2011-03-07 12:09:00 Elapsed time: 3 sec.
2011-03-07 12:09:00 (logapi.cpp (184) err=1 sys=0) SBL-GEN-00001: (logapi.cpp: 184) error code = 1, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
Cause
The cause is related to ODBC data source. Data Source Name for both source and target Database is the same:
[SBA_81_DSN]
QEWSD=40525
ColumnSizeAsCharacter=1
ColumnsAsChar=1
ArraySize=160000
ServerName=<source DB>
Driver=/app/sba_81/siebsrvr/lib/SEor823.so
[SBA_81_DSN]
QEWSD=40525
ColumnSizeAsCharacter=1
ColumnsAsChar=1
ArraySize=160000
ServerName=<target DB>
Driver=/app/sba_81/siebsrvr/lib/SEor823.so
This will cause the import to use the first data source connecting to the first server, <source DB>
Solution
Change the data source name for <target DB> to a different name and rerun the repository migration.keywords: repository, import, dev2prod, migration, SBL-GEN-00001, Unable to verify, ODBC
No comments:
Post a Comment