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.