标签: microsoft-dynamics

我正在尝试使用sys.dm_exec_sessions从context_info列获取信息，如下文所示：Cast(context_info as varchar(128))

在 Dynamics AX 2012 中从 SPID 查找用户会话作者：Amit R. Kulkarni

但是，对于某些行，context_info列为空。有人知道为什么吗？

该数据库是 Dynamics AX 数据库，我使用的查询是：

select cast(context_info as varchar(128)) as ci,* 
from sys.dm_exec_sessions 
where program_name like '%Dynamics%'

这是输出，我不得不删除几列，但这几乎就是它的外观。如果您看到，会话 63 和 87 的 Context_info 为空。

我的查询在没有OPTION (RECOMPILE). 如果不重新编译，运行需要 3-4 分钟，重新编译需要大约 15-20 秒。

我无法更改查询，我已更新所有统计信息并重建所有索引。只有 1 个索引建议，改进了 9.4%。

我试过了：

-- clear all plans in cache
DBCC FREEPROCCACHE

-- Clear Buffer pool
CHECKPOINT
GO
DBCC DROPCLEANBUFFERS
GO

我还能做什么？我无法编辑查询，所以OPTION (RECOMPILE)对我来说不是一个有效的解决方案。查询可能会不时有所不同，因此“计划指南”不起作用？

请注意，这不是实际查询。实际查询由 Dynamics AX 执行，因此使用api_cursor. 我从 中撬出sp_cursorprepare并手动填写了参数。

DECLARE @p1 AS BIGINT = 5637144576
DECLARE @p2 AS NVARCHAR(32) = N'1003'
DECLARE @p3 AS NVARCHAR(32) = N'posp%'
DECLARE @p4 AS BIGINT = 5637144576
DECLARE @p5 AS NVARCHAR(32) = N'sv'
DECLARE @p6 AS NVARCHAR(32) = …

我在工作中偶然成为了一名 DBA，当我接手它时，安静得一团糟。幸运的是，我们已获准构建新系统以升级我们的会计系统：Microsoft Dynamics GP。我想遵循或超越 Microsoft 的所有建议。我们当前的环境存在严重的性能问题。我想得到这个论坛对我们 SA 对我们新系统配置的计划的看法，与 Microsoft 推荐的相比。

就磁盘配置而言，Microsoft 建议：

• 操作系统/应用程序 RAID 1
• SQL 日志 RAID 1
• SQL 数据 RAID 5
• SQL 临时数据库 RAID 1
• SQL 备份 RAID 0。

我们的 SA 可用的是：带有 VNXe 3200 SAN 的 VMware 6 数据中心。该 SAN 有 11 个 600 GB 10k RPM 驱动器和 9 个 2TB 7.2k RPM 驱动器。它还具有 6 个 200GB 闪存驱动器，可用作最常访问数据的高速缓存。因此，推荐的硬盘规格似乎没有考虑到像我们这样虚拟化的数据中心。他将所有 10k RPM 驱动器汇集到一个 RAID 6 + 1 热备件中，将所有 7.2k RPM 驱动器汇集到第二个 RAID 6 + 1 热备件中，并分别将它们标记为性能池和容量池。他放入一个卷的盘片越多，他可以获得的性能就越高，再加上 RAID 6 和热备份带来的所有冗余。但是，他希望将数据库的很大一部分存放在该缓存中。

鉴于我们的会计系统和它的SQL …

SQL Server 2008 R2，Dynamics AX 2009 我们有这个丑陋的查询

DECLARE @P1 NVARCHAR(5), @P2 INT, @P3 INT, @P4 NVARCHAR(11), @P5 INT, @P6 NVARCHAR(5), @P7 NVARCHAR(11)SELECT A.SALESID,
   A.LINENUM,
   A.ITEMID,
   A.SALESSTATUS,
   A.LEDGERACCOUNT,
   A.NAME,
   A.EXTERNALITEMID,
   A.TAXGROUP,
   A.QTYORDERED,
   A.SALESDELIVERNOW,
   A.REMAINSALESPHYSICAL,
   A.REMAINSALESFINANCIAL,
   A.COSTPRICE,
   A.SALESPRICE,
   A.CURRENCYCODE,
   A.LINEPERCENT,
   A.LINEDISC,
   A.LINEAMOUNT,
   A.CONFIRMEDDLV,
   A.RESERVATION,
   A.SALESUNIT,
   A.DIMENSION,
   A.DIMENSION2_,
   A.DIMENSION3_,
   A.PRICEUNIT,
   A.PROJTRANSID,
   A.INVENTTRANSID,
   A.CUSTGROUP,
   A.CUSTACCOUNT,
   A.SALESQTY,
   A.SALESMARKUP,
   A.INVENTDELIVERNOW,
   A.MULTILNDISC,
   A.MULTILNPERCENT,
   A.SALESTYPE,
   A.BLOCKED,
   A.COMPLETE,
   A.REMAININVENTPHYSICAL,
   A.TRANSACTIONCODE,
   A.TAXITEMGROUP,
   A.TAXAUTOGENERATED,
   A.UNDERDELIVERYPCT,
   A.OVERDELIVERYPCT,
   A.BARCODE,
   A.BARCODETYPE,
   A.INVENTREFTRANSID,
   A.INVENTREFTYPE,
   A.INVENTREFID,
   A.ITEMBOMID,
   A.LINEHEADER,
   A.SCRAP,
   A.DLVMODE,
   A.INVENTTRANSIDRETURN,
   A.PROJCATEGORYID,
   A.PROJID,
   A.INVENTDIMID,
   A.TRANSPORT,
   A.STATPROCID, …

我有迟钝。

任何人都可以查看此计划(PasteThePlan) 并告诉我需要优化的内容吗？这是实际的计划。

这是从应用程序获取客户信息的过程的一部分。在跟踪中我发现查询需要很长时间。大约需要 14 秒，而在另一个 POS 中则不到 1 秒。

我使用的是 SQL Server 2016 - Express Edition