2017-02-23 20 views
0

突然Dynamics MSCRMデータベースで実行されているクエリの実行時間が急激に増加しました。以前に存在していたインデックス作成やその他の設定に変更はありませんでした。クエリを実行して30秒かかることがありましたが、現在は4分以上かかるようになっています。Microsoft Dynamics CRM 2016 - 2つのMSCRMデータベースが同じ構成を持ちます.1つは良好なパフォーマンスで動作し、もう1つは低いパフォーマンスで動作します。

クエリ:AsyncOperationBaseテーブルが大きくなりすぎると

SELECT 
    Filterederi_salesengagement.eri_salesengagementnumber , 
    Filterederi_salesengagement.eri_name , 
    Filterederi_salesengagement.eri_salestrackname , 
    Filterederi_salesengagement.eri_salesstagename , 
    Filterederi_salesengagement.eri_statusofbusinessname , 
    Filterederi_salesengagement.eri_statusofsalesprocessname , 
    Filterederi_salesengagement.eri_totaldealvalue_base 
FROM 
    Filterederi_salesengagement 
WHERE 
    Filterederi_salesengagement.eri_statusofbusinessname='Ongoin‌​g' 
+0

こんにちはyouldあなたは遅いクエリとあなたのデータのサンプルを投稿しますか? – PeterRing

+0

構成+パフォーマンスの低下はありません=データが多くなり、クエリに時間がかかります。または、ハードウェアに障害が発生してサーバーが減速する – Alex

+0

パフォーマンスの良いCRMデータベースは、パフォーマンスの低いCRMデータベースがホストされているサーバー(ハードウェア)の同じレプリカでホストされています。私の最初の考えは、常にボトルネックになっているFiltered Viewのパフォーマンスです。 –

答えて

0

パフォーマンスが遅くなります。 Organization_MSCRM DBで次のスクリプトを実行してみてください。

IF EXISTS (SELECT name from sys.indexes 
WHERE name = N'CRM_AsyncOperation_CleanupCompleted') 
     DROP Index AsyncOperationBase.CRM_AsyncOperation_CleanupCompleted 
GO 
CREATE NONCLUSTERED INDEX CRM_AsyncOperation_CleanupCompleted 
ON [dbo].[AsyncOperationBase] ([StatusCode],[StateCode],[OperationType]) 
GO 

while(1=1) 
begin 
declare @DeleteRowCount int = 10000 
declare @rowsAffected int 
declare @DeletedAsyncRowsTable table (AsyncOperationId uniqueidentifier not null primary key) 
insert into @DeletedAsyncRowsTable(AsyncOperationId) 
Select top (@DeleteRowCount) AsyncOperationId from AsyncOperationBase 
where 
    OperationType in (1, 9, 12, 25, 27, 10) 
    AND StateCode = 3 
    AND StatusCode in (30, 32) 

select @rowsAffected = @@rowcount 
delete poa from PrincipalObjectAccess poa 
    join WorkflowLogBase wlb on 
    poa.ObjectId = wlb.WorkflowLogId 
    join @DeletedAsyncRowsTable dart on 
    wlb.AsyncOperationId = dart.AsyncOperationId 
delete WorkflowLogBase from WorkflowLogBase W, @DeletedAsyncRowsTable d 
where 
    W.AsyncOperationId = d.AsyncOperationId    
delete BulkDeleteFailureBase From BulkDeleteFailureBase B, @DeletedAsyncRowsTable d 
where 
    B.AsyncOperationId = d.AsyncOperationId 
delete BulkDeleteOperationBase From BulkDeleteOperationBase O, @DeletedAsyncRowsTable d 
where 
    O.AsyncOperationId = d.AsyncOperationId 
delete WorkflowWaitSubscriptionBase from WorkflowWaitSubscriptionBase WS, @DeletedAsyncRowsTable d 
where 
    WS.AsyncOperationId = d.AsyncOperationID 
delete AsyncOperationBase From AsyncOperationBase A, @DeletedAsyncRowsTable d 
where 
    A.AsyncOperationId = d.AsyncOperationId 
/*If not calling from a SQL job, use the WAITFOR DELAY*/ 
if(@DeleteRowCount > @rowsAffected) 
    return 
else 
    WAITFOR DELAY '00:00:02.000' 
end 
+0

上記のクエリを実行しましたが、残念ながらそれは機能しませんでした。 –

+0

フィルターを適用したビュー定義を確認し、システム生成関数 "fn_GetSharedRecordIdsForFilteredView"がここで問題を引き起こしていることがわかりました。 performacneの問題を引き起こす可能性のあるこの機能に関する考え方 –

関連する問題