Applies to:
Error Message Area:Generic - GENVersion:Siebel 8.1
Purpose
This document is intended to provide cause and corrective action information about Siebel Error Message SBL-GEN-03001: Error allocating %1Scope
This document is informational and intended for any user.SBL-GEN-03001: Error allocating %1
Explanation
Unable to allocate memory for the specified entity. Most likely, memory resources on the machine are exhausted.Corrective Action
Check available memory on the machine.Applies to:
Siebel Assignment Manager - Version: 8.0.0.5 [20420] and later [Release: V8 and later ]Information in this document applies to any platform.
Symptoms
Customer recently added some organizational skills to their skill tables by migrating the data from their development. Upon this change, the assignment manager component is crashing when restarted. This means no objects can be assigned and it is holding up their business.
Customer is receiving a SBL-GEN-03001 error upon restart at the point of the organizational skill load.
Cause
SBL-GEN-03001 indicates that there are not enough memory resouces to perform the requested action. In this case, Assignment Manager is attempting to load the organizational skills into the skill cache at the time the crash occur. So, this would indicate that there are inadequate memory resources available for the number of skills.
Prior to this issue there were 25.7 million skill items, now there are over 26 million.
Customer discloses that not all skill items in the table are active.
Part of the Assignment Manager process when starting is to create a skill cache in memory. This allows assignment manager to perform at a higher level when assigning records. If there are inadequate memory resources available for the skills, then assignment manager cannot create the cache.
Solution
It was discovered that when the skill item is deleted, the
corresponding skill item detail is not also deleted. This was causing a
large number of orphaned records in the skill table. CR 12-1XZBSYJ has been opened to address these orphaned records.
Customer is going to prepare SQL or PL/SQL to clean the orphaned data from the table.
it is recommended that a backup of the table be taken prior to these actions executing.
References
BUG:10592003 - SBL-GEN-03001: ERROR ALLOCATING DYNARRCREATE ORGANIZATION SKILL ITEMSApplies to:
Siebel Assignment Manager - Version: 7.8.2.5 SIA [19227] and later [Release: V7 and later ]Information in this document applies to any platform.
Symptoms
We started the Batch Assignment task to assign one contact:TaskConfig TaskCfgParamInit 4 0 2010-04-02 12:17:08 Assignment Object Name : Contact
TaskConfig TaskCfgParamInit 4 0 2010-04-02 12:17:08 Object Where Clause : where row_id='BBL-6YZ'
The task failed to start up while loading the assignment rules with the error:
GenericLog GenericError 1 0 2010-04-02 12:24:28 (asgnsrvr.cpp (1035) err=3001 sys=0) SBL-GEN-03001: (asgnrule.cpp: 4269) error code = 3001, system error = 2, msg1 = DynArrCreate pRuleApi->ruleItemArr, msg2 = (null), msg3 = (null), msg4 = (null)
There were 3840 new assignment rules imported via EIM in the environment.
Cause
Large number of assignment rules with criteria and values exhausting Batch Assignment component memory while loading them at task start-up. It hits the 2 GB heap memory limit is at machine/OS level.
Look up in Assignment Rules UI in Site Map > Administration - Assignment > Assignment Rules List, very few are expired. And select count(*) SQL right before the error from AsgnBatch log:
SELECT COUNT(*)
FROM SIEBEL.S_ASGN_RULE CR, SIEBEL.S_ASGN_RULE_ITEM VAL, SIEBEL.S_ASGN_GRP R,
SIEBEL.S_ASGN_RULE_GRP RG, SIEBEL.S_ASGN_RULE_GRP RG1,
SIEBEL.S_ASGN_ITEM_TYPE ACR
WHERE
CR.ASGN_GRP_ID = R.ROW_ID
AND VAL.ASGN_RULE_ID= CR.ROW_ID
AND RG.ROW_ID=R.ASGN_RULE_GRP_ID
AND RG.ROOT_RULE_GRP_ID=RG1.ROW_ID
AND RG1.KEY_BASED_FLG = 'N'
AND ACR.NAME = CR.ITEM_TYPE_NAME
AND ACR.REPOSITORY_ID = ?
AND ACR.INACTIVE_FLG='N'
AND CR.TEMPLATE_FLG='N'
AND (R.EFF_END_DT >= {fn now()} OR R.EFF_END_DT IS NULL)
SQLSlowQuery Bind Variables 4 0 2010-04-02 12:24:05 01:1-PT64-1
returns 2740281 rows which is a high number.
Solution
Immediate solution is to reduce the number of assignment rules by deleting assignment rules. Customer worked with their Assignment Admin person to delete assignment rules. After that Batch Assignment worked.For the long term, you may look at engaging Oracle Consulting/Expert Services to review the rules and optimize them to a lesser number.
Additional information:
Siebel Server is a 32 bit application. For each process, the memory limit is 4 GB. In Windows, the heap limit is 2 GB. Batch Assignment (AsgnBatch) is a Siebel component. It's a process at runtime. In order to improve the runtime performance ASAP, AsgnBatch loads all rule/criteria/employee/position/org/skill/skill items into heap memory at starting up. We never set any limit on this. 2 GB is a 32 bit machine and OS limit. We have no way to overcome this.
By the way 2 GB is not only for rules, all other stuff likes skill reside in heap also. We can't use the number of rules to determine how much memory is needed since 1 rule may has a lot of criteria while the other 1 only has a few.
AsgnBatch support loading all rules or some rules within one rule group.
Set the AsgnKey to a rule group Id while submitting server request to AsgnBatch.
Then AsgnBatch will just load the rules with the rule group Id.
Too many rules is not a good thing for Assignment Manager. You can try to divide the existing rules into several different rule groups. But this may fail again if the customer has a large number of rules within one rule group. We don't have limit on number of assignment rules, the 2 GB memory limit is at machine/OS level.
Actually 1 Siebel Server is enough. For example, we have rule group 1 and 2. When you submit request to AsgnBatch, if you specify the AsgnKey = group 1, only the rules under rule group 1 will be loaded.
Of course you can submit another request to AsgnBatch with AsgnKey = group 2. This is different with the server key mapping for Assignment Manager (AsgnSrvr) component.
Applies to:
Siebel Assignment Manager - Version: 8.1.1.2 SIA[21215] and later [Release: V8 and later ]Information in this document applies to any platform.
Symptoms
On : 8.1.1.2 SIA[21215] version, Assignment Manager
When attempting to Start Assignment Manager
the following error occurs.GenericLog GenericError 1 000053d84dd91268:0 2011-05-22 12:45:41 (asgnrule.cpp (6963) err=3001 sys=2) SBL-GEN-03001: Error allocating DynArrCreate pRuleApi->EmpArr
ERROR
-----------------------
SBL-GEN-03001
STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Start Assignment Manager
2. Wait
3. component crashes
Due to this issue, users cannot have records assigned as expected.
Cause
Upon restart, Assignment Manager will build a cache of candidates for assignment that is held in memory. A Significant change in the number of employees is pushing this memory cache beyond its limits.
SBL-GEN-03001 is indicative of a memory problem per <>. Additionally customer has indicated that they recently added over 900,000 employees to the database, many of which are terminated
Solution
The solution is to use the Active Employee Where Clause parameter on the Assignment Manager component to limit the number of employees loaded into cache on component restart.1. In Server Configuration > Server >Components locate the Assignment Manager Component, Parameters
2. Locate the Employee Where Clause Paramenter
3. Enter the where clause, in SQL formatting, not Siebel formatting, to select only the employees to be considered for assignment. In this case, customer chose the where clause WHERE emp.EMPLOYEE_STATUS_CD = 'HR'
No comments:
Post a Comment