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
