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 all
NOTE: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 later
z*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-00001
Hi 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/ Setup
Solution
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.3
We 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-MU33J
Solution
Description:
------------
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/ Setup
Solution
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-18GQP3H
Solution
For benefit for other users, customer was trying to export repository
using repimexp.exe for all languages in Siebel 7.7.1 release.
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
אין תגובות:
הוסף רשומת תגובה