SBL-SVR-01069
Applies to:
Siebel Scheduling - Version: 7.8.2.2 SIA [19219] and later [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.8.2.2 [19219] NLD Pub Sect
Database: Oracle 10g
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-3035897353.
Symptoms
The customer had created a new Siebel environment and copied the
database from another existing environment to this new environment.
-
The initial server key mappings for the Appointment Booking Service
(ABS) were in the database when it was copied to the new environment.
This means that the new environment had server key mappings which
pointed to a non-existing server.
- When it was first started, ABS errored out due to the fact that the server key mappings were invalid.
-
The server key mappings were updated with the new Siebel server name,
and the Siebel service was restarted after changing the server key
mappings.
- When the Siebel server is restarted, the ABS tries to start but fails with SIGABRT.
The Siebel server log says:
..
ServerLog
ProcessCreate 1 0 2006-05-10 16:03:18 Serverproces met
meerdere threads aangemaakt (PID besturingssysteem = 376842) voor
Appointment Booking Engine met taak-ID 6306
ServerLog ProcessExit
1 0 2006-05-10 16:04:02 ApptBook 6306
SBL-OSD-02006 Process exited with error - Proces beëindigd vanwege
ontvangen van signaal SIGABRT.
..
After 10 retries it gives up.
In the ApptBook log it says:
..
GenericLog
GenericError 1 0 2006-05-09 18:21:30 (scirkey.cpp (215)
err=2001069 sys=0) SBL-SVR-01069: Deze component, die gebruikmaakt van
unieke sleutels, probeert een bestaande sleutel vast te leggen (1-URXGL)
GenericLog
GenericError 1 0 2006-05-09 18:21:30 (scirkey.cpp (987)
err=2001069 sys=0) SBL-SVR-01069: Deze component, die gebruikmaakt van
unieke sleutels, probeert een bestaande sleutel vast te leggen (1-URXGL)
Execution
Warning 2 0 2006-05-09 18:21:30 De engine kan
serviceregio 1-URXGL (1) niet registreren bij Siebel Server SRCWIT102.
Execution
Warning 2 0 2006-05-09 18:21:30 De engine kan geen
serviceregio registreren bij Siebel Server SRCWIT102.
..
This behavior happens when executing the BusSvcMgrInit and ReloadServiceRegion methods.
Translation of error messages:
* SBL-OSD-02006 - Process exited because it received signal SIGABRT.
* SBL-SVR-01069 - This component is using unique keys and it is trying to register an existing key (1-URXGL)
* SBL-ABS-00109 - The engine failed to register any service region with Siebel server 'SRCWIT102'
Cause
The behavior was caused by the previously existing server key mappings pointing to a different environment.
It
seems that somewhere the server key mapping is stored and even after
updating it and restarting the Siebel server, it still has not
deregistered the previous server key.
Solution
Just changing the server key mappings to the correct Siebel server did not resolve the behavior.
It was necessary to recreate the mappings by deleting and adding the correct lines.
Keywords: SBL-ABS-00109, SBL-ABS-00110, Server Key Mappings, Register,
Service Region, BusSvcMgrInit, ReloadServiceRegion, ApptBook, ABS,
Optimizer
Applies to:
Siebel Scheduling - Version: 8.0.0.8 SIA[20430] and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
ABS is not loading the service regions on all Siebel Servers upon Siebel Server service or ApptBook component restart.
Specific Error Message:
GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-113)
GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-113)
Execution Warning 2 000000054ca3f0fe:0 2010-09-29 17:39:06 The
engine failed to register service region '1-8E7-113 (1)' with Siebel
Server 'aixprd10'.
GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-100)
GenericLog GenericError 1 000000054ca3f0fe:0 2010-09-29 17:39:06
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-8E7-100)
Execution Warning 2 000000054ca3f0fe:0 2010-09-29 17:39:06 The
engine failed to register service region '1-8E7-100 (2)' with Siebel
Server 'aixprd10'.
Sequence of Event:
1. Restart Siebel Server service or ApptBook component.
The ApptBook component is enabled and online.
2. Service Regions are loaded in ABS cache with error SBL-SVR-01069.
What is working:
Click on Load ABS on each Service Region to reload all the service
regions, and all are loaded and registered successfully without error
SBL-SVR-01069.
Environment:
Affecting Assignment Booking in both UAT and Production environments.
Siebel version: 8.0.0.8 SIA [20430] QF0858 , Siebel Server: IBM AIX on POWER Systems (32-bit), Database: Oracle 10.2.0.4
UAT has one Siebel Server 'aixuat06', it is a multi-processor machine.
Production has two Siebel Servers 'aixprd10' and 'aixprd14', both are multi-processor machines.
Cause
On multiprocessor machine, Service Regions can be mapped to ApptBook
component on multiple processess, and each process is represented by a
process#. It is accomplished by setting MinMTServers = MaxMTServers >
1for ApptBook component, e.g., MinMTServers = MaxMTServers = 4 for
ApptBook component. And the error SBL-SVR-01069 in loading Service
Regions only happens to Service Regions mapped to multiple processes,
i.e., more than one process#. If Service Regions are mapped to ApptBook
component on one process only which is accomplished by setting
MinMTServers = MaxMTServers = 1, then the error SBL-SVR-01069 doesn't
happen when loading Service Regions.
The service regions loaded in the very 1st process don't have the error,
and in ApptBook log for Process 1 doesn't have any error, this can be
seen in ApptBook_0025_26214403.log from Logs_101310.zip:
Execution Trace 3 000000054cb670ee:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWC (1)' with siebel server 'aixuat06'.
Execution Trace 3 000000054cb670ee:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWO (1)' with siebel server 'aixuat06'.
The service regions loaded after 1st process have the error, because for
each process ApptBook always starts with all service regions with
Service Region's ROW_ID and Process# in ascending order, we can see from
ApptBook_0027_28311555.log from Logs_101310.zip the SQL being executed
in the log that select all service regions with Service Region's ROW_ID
in ascending order, and the error:
ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 SELECT statement with ID: 3056F2F8
SELECT /*+ ALL_ROWS */
T2.CONFLICT_ID,
T2.LAST_UPD,
T2.CREATED,
T2.LAST_UPD_BY,
T2.CREATED_BY,
T2.MODIFICATION_NUM,
T2.ROW_ID,
T2.COMPONENT_ID,
T1.NAME,
T2.PROCESS_NUM,
T2.SERVER_NAME,
T2.SRV_REGN_ID
FROM
SIEBEL.S_SRM_ACTION T1,
SIEBEL.S_SCH_SRV_MAP T2
WHERE
T2.COMPONENT_ID = T1.ROW_ID AND
(UPPER(T2.SERVER_NAME) LIKE UPPER(:1) AND T1.NAME = :2)
ORDER BY
T2.PROCESS_NUM, T2.SRV_REGN_ID
ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 Bind variable 1: aixuat06
ObjMgrSqlLog Detail 4 000000054cb6901c:0 2010-10-13 16:11:26 Bind variable 2: ApptBook
GenericLog GenericError 1 000000054cb6901c:0 2010-10-13 16:11:27
(scirkey.cpp (232) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-EEUQWC)
GenericLog GenericError 1 000000054cb6901c:0 2010-10-13 16:11:27
(scirkey.cpp (1047) err=1311789 sys=0) SBL-SVR-01069: This component is
using unique keys and it is trying to register an existing key
(1-EEUQWC)
Execution Warning 2 000000054cb6901c:0 2010-10-13 16:11:27 The engine
failed to register service region '1-EEUQWC (1)' with Siebel Server
'aixuat06'.
The ones already loaded will get the error, as shown as above error,
until it gets to the ones to be loaded on the designated process#, and
then load them successfully in the designated process#:
Execution Trace 3 000000054cb6901c:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQVX (2)' with siebel server 'aixuat06'.
Execution Trace 3 000000054cb6901c:0 2010-10-13 16:11:27 The engine
registered service region '1-EEUQWX (2)' with siebel server 'aixuat06'.
And it goes like this until all Service Regions in all processes are loaded.
Solution
1. Use the existing Service Region configuration in place which is multiple server processor mappings, no changes needed:
- MinMTServers = MaxMTServers = 4 for ApptBook component on each Siebel Server.
- Map Service Regions to one of the 4 process#: 1, 2, 3, 4 for ApptBook
component on Siebel Servers in Server Key Mappings In client application
> Site Map > Administration - Scheduling:
PROCESS_NUM SERVER_NAME SRV_REGN_ID COMPONENT_ID
4 aixuat06 1-EEUQVL 1-35D5
4 aixuat06 1-EEUQVO 1-35D5
3 aixuat06 1-EEUQVR 1-35D5
3 aixuat06 1-EEUQVU 1-35D5
2 aixuat06 1-EEUQVX 1-35D5
3 aixuat06 1-EEUQW0 1-35D5
3 aixuat06 1-EEUQW3 1-35D5
3 aixuat06 1-EEUQW6 1-35D5
4 aixuat06 1-EEUQW9 1-35D5
1 aixuat06 1-EEUQWC 1-35D5
4 aixuat06 1-EEUQWF 1-35D5
3 aixuat06 1-EEUQWI 1-35D5
3 aixuat06 1-EEUQWL 1-35D5
4 aixuat06 1-EEUQX0 1-35D5
1 aixuat06 1-EEUQWO 1-35D5
3 aixuat06 1-EEUQWR 1-35D5
4 aixuat06 1-EEUQWU 1-35D5
2 aixuat06 1-EEUQWX 1-35D5
2. The error SBL-SVR-01069 in loading Service Regions in the multiple
processor mappings should be benign and can be ingored. The Service
Region's Server Key Mappings should be correct. The Documentation
Enhancement CR 10602873 has been created to document the following in
Siebel Field Services Guide:
=====
Multiple Processor Support documentation needs to include the following:
Restarting Siebel Server which restarts ApptBook component, you get
error SBL-SVR-01069 in Process 2 trying to load the Service Region
already loaded on Process 1:
SBL-SVR-01069: This component is using unique keys and it is trying to register an existing key (1-CSIQ)
The engine failed to register service region '1-CSIQ (1)' with Siebel Server 'siebsrvr1'.
Book an appointment with service region 1-CSIQ right after without
reloading by executing Load ABS on 1-CSIQ, and it is successful.
Explanation is as long as Service Regions are mapped to multiple
processes, you will get SBL-SVR-01069 for higher process# > 1 because
Service Regions are loaded sequentially starting with lowest process#
during ApptBook component starts up, the error SBL-SVR-01069 is
informational, it is benign.
=====
Applies to:
Siebel Scheduling - Version: 7.5.3.4 SIA [16180] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3.4 SIA [16180] and above
Database: Any Database
Application Server OS: Any Application Server OS
Database Server OS: Any Database Server OS
This document was previously published as Siebel SR 38-2743675661.
Symptoms
Customer created a workflow process which uses the "Server Request"
business service to submit a request to the Appointment Booking Service
(ABS) to run the ReloadServiceRegion method. This workflow process is
scheduled to run every day at 5:00 AM.
When the Siebel Server
services first come up, the Appointment Booking Engine is also online
and the ApptBook component is able to register each service region and
load each service region into cache. Users are then able to book
appointments throughout the day. However, once the workflow process to
reload service region is executed the following happens:
a. The resulting ApptBook task that attempts to reload service regions fails with error message:
GenericLog
GenericError 1 2005-12-16 05:02:33 (scirkey.cpp 13(986)
err=2001069 sys=0) SBL-SVR-01069: This component is using unique keys
and it is trying to register an existing key ((null))
Execution
Warning 2 2005-12-16 05:02:33 The engine failed to register
service region '1-1J6MMA (1)' with Siebel server 'V04751S846'.
b.
The ApptBook component stopped returning appointments to the users.
Rather, the ApptBook component returned an error message to the user as
follows:
ApptBook with key [1-1J6MMA] is not available
Cause
Upon checking the customer's log files, they revealed the following:
----------------------------------------
[1] The ApptBook component came up when Siebel Server started:
ServerLog
ProcessCreate 1 2005-12-15 16:49:30 Created multithreaded
server process (OS pid = 3032) for Appointment Booking Engine with task
id 51265
....
ServerLog ProcessCreate 1 2005-12-16
05:02:18 Created server process (OS pid = 2836) for Siebel Server
Scheduler with task id 51499
; A new ApptBook process started here,
before the original one even completed. It is unclear at this time why a
new ApptBook process was started.
....
ServerLog ProcessExit 1 2005-12-16 05:17:05 ApptBook 51265 SUCCESS Process completed Successfully
; After 15 minutes the original ApptBook process was shutdown.
----------------------------------------
[2]
In the ApptBook_51265.log component log file for the above old process,
we can see all 4 service regions registered and loaded:
2021
2005-12-15 16:49:31 2005-12-16 05:17:05 -0500 00003f99 001 001f 0001 09
ApptBook 51265 3032 3028 C:\sea752\siebsrvr\log\ApptBook_51265.log
7.5.3.12 [16272] ENU
....
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1J6MMA (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1J6MMB (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1LFGZZ (1)' with
siebel server 'V04751S846'.
Execution Trace 3 2005-12-15
16:50:06 The engine registered service region '1-1LFH00 (1)' with
siebel server 'V04751S846'.
....
----------------------------------------
[3] For the new ApptBook process, the component tried to register a service region with the Server Request Broker but failed:
2021
2005-12-16 05:02:18 0000-00-00 00:00:00 -0500 00000000 001 001f 0001 09
ApptBook 51499 2836 2812 C:\sea752\siebsrvr\log\ApptBook_51499.log
7.5.3.12 [16272] ENU
....
GenericLog GenericError 1
2005-12-16 05:02:33 (scirkey.cpp 13(214) err=2001069 sys=0)
SBL-SVR-01069: This component is using unique keys and it is trying to
register an existing key (1-1J6MMA)
GenericLog GenericError 1
2005-12-16 05:02:33 (scirkey.cpp 13(986) err=2001069 sys=0)
SBL-SVR-01069: This component is using unique keys and it is trying to
register an existing key ((null))
Execution Warning 2
2005-12-16 05:02:33 The engine failed to register service region
'1-1J6MMA (1)' with Siebel server 'V04751S846'.
ObjMgrBusCompLog Delete 4 2005-12-16 05:02:33 BusComp was deleted d8bd578 "Scheduler Server Keys"
SQL SQL 4 2005-12-16 05:02:33 4 row(s) retrieved by ID: D9DDB20
Execution
Warning 2 2005-12-16 05:02:33 The engine failed to register
any service region with Siebel server 'V04751S846'.
ObjMgrBusServiceLog
InvokeMethod 4 2005-12-16 05:02:33 Business Service
'Appointment Booking Service' invoke method 'BusSvcMgrInit' Execute
Time: 0.178 seconds.
....
It seems that the original ApptBook
process/pid was up along with the Siebel Server services and it was
working fine. However, somehow another ApptBook process got started and
caused the original one to shutdown. The new pid was not able to
register with SRBroker as SRBroker already saw the same key from the
earlier ApptBook task, and it cannot register an existing key.
----------------------------------------
[4] When checking one of the ApptBook log files that had some parameter information, this information was found:
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Maximum MT Servers : 5
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Memory-based multithread component recycling : FALSE
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Process memory usage limit : 1500
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Minimum MT Servers : 1
TaskConfig TaskCfgParamInit 4 2005-12-16 05:02:18 Maximum Tasks : 20
Note how Max MT = 5, meaning that if needed, there can be 5 ApptBook concurrent processes running.
Min MT = 1, meaning that when ApptBook component first comes online, only one ApptBook process is running.
Maximum
Tasks = 20, meaning that 1 process can only handle 20 concurrent tasks.
If the 21st request comes into ApptBook, then a new ApptBook process is
started up to handle the 21st - 40th concurrent tasks. This is the
reason why the new ApptBook process was automatically started while the
original ApptBook process was still running.
However, the new
ApptBook process could not register itself nor the service regions with
SRBroker because the Server Key Mappings says that all service regions
are running on ApptBook process # 1 (Process # 1 being the 1st ABS
process that was started from the Siebel server services startup).
Solution
In order to address this behaviour, customer was suggested to do the following:
1.
Customer currently has all service regions registered to Process # 1 of
ABS. Thus, they should only have Minimum MT Server = 1. If it is
expected that there would be more than 20 concurrent tasks for ABS, the
Maximum Tasks parameter value on on ABS can be increased to 100 tasks.
2.
Then, change the Maximum MT Server on ABS to 1, so that there is only
one ABS process running on the system since all the service regions in
this case are registered to only 1 process anyway.
3. After applying above changes, restart the Siebel servers.
If
having Min and Max MTS = 1 and Maximum Tasks = 100 is not able to
support the number of concurrent requests for ABS, another alternative
is to do the following:
Set Min and Max MTS = 4
Update the Service Region's Server Key Mapping to have 1 Service Region per ApptBook Process #:
Service Region 1 -> Process # 1
....
Service Region 4 -> Process # 4
This way, the load can be distributed across multiple ApptBook processes according to service regions.
This
customer applied the approach to set Min MT = 1, Max MT = 1, Max Tasks =
100, all 4 service regions mapped to Process # 1 of ApptBook component,
and this setting helped resolve the behaviour they were seeing. When
their workflow runs to reload service regions, each service region was
reloaded successfully. In addition, the ApptBook component continued to
work properly to return appointments to the users after the service
region cache was updated.
Search keywords: ABS, apptbook,
book appointment, reload service region, workflow, submit, request,
error, failure, component, restart, shutdown, recycle, startup, This
component is using unique keys and it is trying to register an existing
key , The engine failed to register service region, ApptBook with key,
is not available, process, multiple, MTS, MT, minimum, maximum, tasks
Applies to:
Siebel System Software - Version: 7.7.2 [18325] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Professional)
Version: 7.7.2 [18325] FRA
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-1889334041.
Symptoms
SBL-SVR-01069
Dear support,
For your general understanding:
LoyEngineBatch is configured with following parameters:
LOY - Engine Queue Objects: Transaction:500,Tier:15
LOY - Engine Number of Runs: - 1
We have defined 50 server Keys and assigned them to 2 processes
we need to find the way to submit component request, which would:
1. process transactions (in order to update member field attributes)
2.
process tiers (the search spec takes into account member field
attributes which are updated by the processing of transactions)
Would it be possible that only one object type would get processed with the dos cmd below ?
a) We have processed transactions and tiers with following dos cmd:
start task for component LoyEngineBatch
start task for component LoyEngineBatch
sleep 60
start task for component LoyEngineBatch
start task for component LoyEngineBatch
start task for component LoyEngineBatch
start task for component LoyEngineBatch
b)
We have queried in the database and realised that for members which
were assigned to process 2, transactions were processed but not the
tiers.
c) we have shutdowned the component and resumed our test: tiers were all processed.
How can we avoid this from happening ?
Solution
Message 1
For the benefit of the readers,
Question: During the
implementation of the Loyalty environment, some questions were raised
about the starting of tasks from the command line. The reproduction of
this behavior and the troubleshooting of this lead to the following
information raised/clarified.
Resolution:
*You need to set
the MinMTServer=MaxMTServer=<Number of Loyalty Process on your
Siebel server>=2 for the sake of the example. This is independent on
the number of Server Key you will associate to each pair server/process.
*In
order to start the Loyalty Batch Engine, you can either run a "Workflow
Process Manager" job for the process "LOY Engine - Start Engine" in
which you will set the number of processes and the number of thread per
process to the value required for your environment. Both are set to 1 by
default. This will start a number of Batch Engine tasks as per the
formula (1 + (1 + Thread/Process #)) * # of Processes which is a minimum
of 3 tasks per process. This makes 6 tasks in our example.
*You can alternatively start these tasks manually as per the customer description.
The
first task will make the MTServer determine to which process it will be
associated. In our example the second task will be associated to the
2nd key. The only way to confirm that is by reading the log in which the
SRMRouting event has been set to 4.
Enhancement Change Request
12-VM0YFD: "Please add a way to read the process associated to a task
via the srvrmgr" has been opened to have an easier way of verification.
Enhancement
Change Request 12-VLY7CK: "Error SBL-SVR-01069 while choosing the
process to work for the LoyEngineBatch tasks" has been opened to remove
this message which is the expected behavior.
*Please note that a the
startup of your server, you will have one log file per MTServer has this
process require to start its listener on a TCP port.
*Please also
note that in the Server Administration task view, you will see the
entries from the S_SRM_REQUEST table which are requests for tasks and
not tasks.
*When you activate a Promotion, this will generate a
request for a task in order to update the Cache in the Batch Engine
MTServer.
*If you do this when the Engine Tasks are not fully
started, this will result in left over request that will need to be
cleaned up with the component SvrTblCleanup.
תגובות
הוסף רשומת תגובה