这段时间,正在进行CRM2011方面的工作,一直都存在一个问题
因为发现数据库,一直在膨胀。
每天30M.
今天抽时间看了看。
看到,有三个表,与第四名不在一个量级。
原因它们三个,占了绝大部分空间。
name | rows | reserved | data | index_size | unused |
AsyncOperationBase | 2042426 | 2809384 KB | 1994608 KB | 806304 KB | 8472 KB |
WorkflowLogBase | 4045276 | 1950696 KB | 1517728 KB | 432536 KB | 432 KB |
PrincipalObjectAccess | 10641923 | 3661480 KB | 1395584 KB | 2265360 KB | 536 KB |
ReportBase | 100 | 27760 KB | 28360 KB | 136 KB | 0 KB |
前面两个分别是系统任务,和工作流,应当手工删除,也没什么影响。
但第三个,到网上查了查,还是有些麻烦。
微软解释说,要升到Rolling Updating 6 才能解决数据和POA一起删除的问题。
这样说来,并不能解决POA变大的问题。
所以,很犹豫是不是进行升级。
希望有这方面经验的人,帮提提建议。
PrincipalObjectAccess–Performance Recommendations
http://blogs.msdn.com/b/crminthefield/archive/2011/06/09/principalobjectaccess-performance-recommendations.aspx
http://blogs.msdn.com/b/ukcrm/archive/2011/07/08/automating-crm-2011-security-rules-with-plug-ins.aspx
http://blogs.msdn.com/b/ukcrm/archive/2011/03/10/using-plug-ins-to-modify-views.aspx
http://support.microsoft.com/kb/2664150
还有,关于纪录共享,我也正在找原因。
Why Large-Scale Sharing Is Bad
Sharing in CRM is designed to provide explicit access to records when the role-based security doesn’t allow it. Whenever a record is shared, an entry is added to the PrincipalObjectAccess table in the database. In addition, depending on the cascading options set on different entity relationships, an entry is added for each child record. For example, suppose you take the out-of-the box account entity and look 1:N relationships to the various child entities (e-mail, phone call, task, appointment, letter, fax, lead, opportunity, quote, order, invoice, contact, case, note etc.). Each time you share the parent account, an entry is added for each child record as well. For large-scale CRM deployments, it doesn’t take long for the PrincipalObjectAccess table to grow to several million records, which can have a major impact on performance.
If you want to understand this in more depth, here are some good articles on the subject:
- Dynamics CRM in The Field Blog: Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent - Cascade All setting
- Dynamics CRM in The Field Blog: PrincipalObjectAccess–Performance Recommendations
Team Ownership As An Alternative To Sharing
New to CRM 2011 is team ownership of records, and it is this feature that I believe offers a more scalable solution to sharing. In order to make this work, I decided that I would have a separate team for each account record, so for a CRM implementation with 40,000 accounts there would be 40,000 teams. I did think about having a team for each portfolio to keep the number of teams to a relatively small number, but there are some possible future requirements that will mean each account may need slightly different user access.
没完全看明白。
==================================
续:
1。 如上所示,数据库变大,有三个表,可以认为两方面主要原因,一个是因为POA,也就是Share 信息,在所属记录被删除后,并没有被删除。
微软给出的官方解决方案为:
http://support.microsoft.com/kb/2664150
大意如下:
1)升级到Rolling Update 6 .
要注意的是升级到期Rolling Update6之前,需要先升级到5。
因为微软已认定,Share信息,没有与记录一起被删除是一个bug。当然是一个bug.
升级的目的是解决这个bug.
2)手动执行一段脚本,用这段脚本把现存错误的POA信息删除。我试了一下,删除了一半的记录。
微软说,只需要执行一次。意思就是说以后就自动删除了(安装RL6之后)。
如果这样,我发现,可以不升级,因为升级到RL6可能会引入新的错误。这是软件公司一贯的做法,升级之后,新的bug又出现了。
比如这三个表的问题,CRM4.0就存在,可是为什么到CRM2011还在那呢?足见微软没有下功夫。
2。第二个原因是工作流。
有许多工作流已完成,但信息还在。因为许多工作流,对我们来说没有意义了,特别是那些每天自动执行的工作流,并且也执行成功了,这种记录,把我们的系统日志都稿得乱七八糟的。所以,应当删除之。
微软解决方案如下:
http://support.microsoft.com/kb/957871
意思是说,在MSCRM注册表:
然后重启IIS: iisreset
3。第三个原因是AsyncOperationBase,系统作业。
这个稍复杂些:
微软的解决方案:
http://support.microsoft.com/kb/968520
另一个解决方案,与微软的一样,只是多了一步建索外,觉得不如微软的。但文章讲得仔细。
http://www.interactivewebs.com/blog/index.php/crm/slow-performance-or-large-database-file-in-ms-crm-asyncoperationbase/
有一家公司,提供了一个free的工具,据说可以解决这个问题:
http://www.interactivewebs.com/crm/AsyncOperationBaseDeleteTool/tabid/2248/Default.aspx
要注意的是,微软建议我们用crm job manager来设定执行这个脚本的动作。
看到这我们知道,这个事是要不断地维护下去。
4。另外,我们几乎可以肯定,这三个表之间,是有关系的。正是因为工作流执行得太多,而且许多工作流是我们公司自己的程序自动调用的,而因为有些用户离职,使得工作流没有执行成功,使得出错的工作流越来越多,每天数千条,
所以,系统日志,也就是系统任务,条目才越来越多。
而由于相关的记录,不段地被创建与删除(因为自动作业作得过于简单,每天只是把所有的清空,重新从SAP导入),而由于CRM的bug,那些被删除的记录的POA信息,并没有被删除,所以POA也变得越来越大。
好了,基本上就这些了。