Dynamics CRM中一个查找字段引发的【血案】

摘要: 本人微信和易信公众号： 微软动态CRM专家罗勇 ，回复267或者20180311可方便获取本文，同时可以在第一间得到我发布的最新的博文信息，follow me！我的网站是 www.luoyong.me 。

在Dynamics CRM中快速查找功能是个让人喜欢的功能，在每个实体的列表界面的右上角有个搜索记录的功能，输入搜索关键字回车后就会执行搜索。

还有Dynamics 365的全局搜索功能也是对指定实体(系统管理员配置)执行快速查找并显示结果。

用户很喜欢快速查找功能，而且在实施项目过程中配置快速查找也很简单，打开实体的类型为【快速查找视图】的视图，在弹出窗口中点击【添加查找列】添加后保存并发布实体可以了。我这里将序列号 productserialnumber 添加为查找列后保存并发布【案例】实体。

快速查找功能配置简单，用户喜欢，那是不是配置的越多越好。有句广告词说的好，【劲酒虽好，可不要贪杯】。我这里就以一个实际例子来说明下一个快速查找列引发的【血案】。

如果某个实体的记录比较多，比如数百万行记录以上，你添加了一个快速查找列，但是Dynamics 365的每天运行的维护作业(maintenance jobs)中的Indexing Management这个作业没有在你添加快速查找列后运行为之添加索引的话，那就可能引发【血案】。使用这个大实体(记录数很多)的快速查找功能，如果再加上对这个字段的值缺乏分析(比如新加字段)，那么可能导致这个快速查找运行非常慢，乃至耗尽数据库服务器的CPU，导致系统用起来非常缓慢甚至不可用(系统报错)。这个可能很多人没有碰到不会在意，希望看到本篇文章的童鞋们吸取教训。

我这里拿一个快速查找的SQL来给大家看看，可以看到我添加的快速查找列 productserialnumber 加入了搜索(Like执行的搜索)中了。

exec sp_executesql N'WITH __QuickFind__ as (select top 10001 [IncidentId] from (
SELECT "incident0".[IncidentId] AS [IncidentId] FROM [IncidentBase] AS "incident0" WITH (NOLOCK)
 where ("incident0".Title like @Title0) OR ("incident0".TicketNumber like @TicketNumber0) OR ("incident0".ProductSerialNumber like @ProductSerialNumber0)) as [__QuickFindInternal__])select
top 51 "incident0".PriorityCode as "prioritycode"
, "incident0".TicketNumber as "ticketnumber"
, "incident0".Title as "title"
, "incident0".CreatedOn as "createdon"
, "incident0".CaseOriginCode as "caseorigincode"
, "incident0".IncidentId as "incidentid"
, "incident0".ProcessId as "processid"
, "incident0".StateCode as "statecode"
, convert(bigint, "incident0".VersionNumber) as "versionnumber"
, case when (select COUNT(*) from [__QuickFind__]) = 10001 then 1 else 0 end as [__QuickFindLimitValue__]
, convert(bigint, "processidworkflowworkflowid".VersionNumber) as "processidworkflowworkflowid.versionnumber"
from
 Incident as "incident0" WITH (NOLOCK)  left outer join Workflow as "processidworkflowworkflowid" WITH (NOLOCK)  on ("incident0".ProcessId  =  "processidworkflowworkflowid".WorkflowId)
where
 [incident0].[IncidentId] in (select [IncidentId] from [__QuickFind__]) order by
 "incident0".Title asc
, "incident0".IncidentId asc',N'@Title0 nvarchar(200),@TicketNumber0 nvarchar(200),@ProductSerialNumber0 nvarchar(200)',@Title0=N'0033%',@TicketNumber0=N'0033%',@ProductSerialNumber0=N'0033%'

既然能引发【血案】，那应该也有阻止【血案】的方法。管理上的改进咱不提了，本文提一下技术方面的三个建议：

• 按官方的建议是一个实体的快速查找列不要超过【六】个，不宜过多。
• 开发程序将本次要发布的内容和现有系统中的内容比较，查看是否增加了快速查找列。将要发布的解决方案用SDK\Bin目录下的SolutionPackager.exe打开，然后比较实体定义文件中的快速查找列定义，看和之前的快速查找定义有啥不同，将不同的显示出来，这样不用去记录本次部署增加了什么快速查找列(实际上也有可能会忘记增加了什么快速查找列)。这个技术上是可行的，我的项目已经在使用。
• 添加快速列后确保在用户大规模使用前维护作业中Indexing Management这个作业会运行，这个作业会为快速查找列添加索引，很大程度上会避免问题。问题来了，这个作业什么时候运行，如何调整让他运行？官方Darren Liu写的博文CRM 2013 Maintenance Jobs 中有介绍（如果前面网址不好用了，用这个网址 https://darrenliu.wordpress.com/2014/04/03/crm-2013-maintenance-jobs/），遗憾的是文中并为提及如何查看以及更改下次运行时间。有个工具叫CRMJobEditor是可以看到和调整，可是调整到很近的时间不行。后来我们找到了靠谱的方法，直接改CRM数据库中的如下记录(注意如果一个部署中有多个组织，下面这个SQL会更新多条语句，请根据自己需要决定什么时候更新)，运行完毕后，这条记录的LastRunTime会变，LastResultCode也会变为0。如果还不放心可以看下是否为新加的快速查找列创建了索引，如下图所示创建了。

  一般先查出来，再修改，注意要修改两个字段的值。

  Select NextRunTime,RecurrenceStartTime,*
  from MSCRM_CONFIG.dbo.ScaleGroupOrganizationMaintenanceJobs
  where OperationType = 15

  然后再执行更改语句，一般不需要更改日期，更改时间就可以了，注意这里用的都是UTC时间，如果你是东八区，需要减去八个小时才是哦。

  update MSCRM_CONFIG.dbo.ScaleGroupOrganizationMaintenanceJobs
  set NextRunTime = '2019-03-08 17:00:00',RecurrenceStartTime='2019-01-20 17:00:00'
  where OperationType = 15

• 

• 很多朋友在问，OperationType字段值及其说明在哪儿查看？这个看实体System Job实体(架构名：AsyncOperation) 的 OperationType 字段的值。我这里简单记录如下：

• Event	1
  BulkEmail	2
  Parse	3
  Transform	4
  Import	5
  ActivityPropagation	6
  PublishDuplicateRule	7
  BulkDetectDuplicates	8
  CollectSqmData	9
  Workflow	10
  QuickCampaign	11
  PersistMatchCode	12
  BulkDelete	13
  DeletionService	14
  IndexManagement	15
  CollectOrgStats	16
  ImportingFile	17
  CalculateOrgStorageSize	18
  CollectOrgDBStats	19
  CollectOrgSizeStats	20
  DatabaseTuning	21
  CalculateOrgMaxStorageSize	22
  BulkDeleteChild	23
  UpdateStatisticIntervals	24
  FullTextCatalogIndex	25
  DatabaseLogBackup	26
  UpdateContractStates	27
  ShrinkDatabase // deprecated	28
  ShrinkLogFile	29
  ReindexAll	30
  StorageLimitNotification	31
  CleanupInactiveWorkflowAssemblies	32
  RecurringSeriesExpansion	35
  ImportSampleData	38
  GoalRollup	40
  AuditPartitionCreation	41
  CheckForLanguagePackUpdates	42
  ProvisionLanguagePack	43
  OrgDBUpdate	44
  SolutionUpdate	45
  RefreshRowCountSnapshots	46
  RefreshReadSharingSnapshots	47
  OptInFcbOrgSync	48
  PostToYammer	49
  OutgoingActivity	50
  IncomingEmailProcessing	51
  MailboxTestAccess	52
  EncryptionHealthCheck	53
  ExecuteSdkMessage	54
  SnapshotIsolationUpdate	55
  UpdateEntitlementStates	56
  IncrementalRollup	57
  BootstrapRollup	58
  ImportTranslations	59
  CleanupOnRollupDelete	60
  CheckFullTextIndexColumnStatus	61
  ConvertDateAndTimeBehavior	62
  EntityKeyIndexCreate	63
  ReadCommittedSnapshotIsolationUpdate	64
  UpdateKnowledgeArticleStates	65
  AddOrgDBOptimization	66
  RemoveOrgDBOptimization	67
  ResourceBookingSync	68
  ActionCardAsync	69
  RefreshRowCountAndReadSharingSnapshots	70
  CleanupSolutionComponentsOperation	71
  AppModuleMetadataOperation	72