我目前在SQL Server 2016 Enterprise上出现了一些奇怪行为的性能问题。
我在数据库中创建了一个新模式,然后在这个模式中创建了一个视图。
现在,当我直接连接数据库时,它包含这个模式和视图,并编写一个简单的查询,如
SELECT * FROM SCHEMA.VIEW
完成需要大约30分钟(!)。完全合格的查询(例如
)也会发生同样的情况SELECT * FROM DB_NAME.SCHEMA.VIEW
但是现在,如果我首先将数据库更改为master或其他用户数据库,然后再跨数据库再次运行查询,则会在大约10秒内完成(!)。两个数据库的数据库属性相同,以及数据库文件和日志文件的已用驱动器。
有没有人知道可能导致这种巨大性能问题的原因?
我在视图中使用了以下代码:
CREATE VIEW [controlling].[UnitLoginHistory]
AS
WITH cte
(
Jahr, UnityId, Unit_UnityId, Analytical_Code, Unit_Code, Unit_Name, Active
, Show_in_org_chart, Begin_Date, End_Date, Unit_Owner_First_Name, Unit_Owner_Last_Name
, Unit_Owner_Login, Unit_Owner_CorporateID, UnityParentId, UnityTypeId, Unit_Level
, Magnitude_Code, ImportDate, ReplicationLevel
)
AS
(
SELECT
dt.Jahr
, a.UnityId
, a.UnityId
, a.Analytical_Code
, a.Unit_Code
, a.Unit_Name
, cast(case when a.Active = 'True' then 1 else 0 end as bit)
, a.Show_in_org_chart
, a.Begin_Date
, a.End_Date
, a.Unit_Owner_First_Name
, a.Unit_Owner_Last_Name
, a.Unit_Owner_Login
, a.Unit_Owner_CorporateID
, a.UnityParentId
, a.UnityTypeId
, a.Unit_Level
, a.Magnitude_Code
, a.ImportDate
, 1
FROM [Staging_INPUT].[DBO].[OBS_Workunit] a
JOIN (
SELECT
YEAR(IMPORTDATE) Jahr
, MAX(IMPORTDATE) Datum
FROM [Staging_INPUT].[DBO].[OBS_Workunit]
GROUP BY
YEAR(IMPORTDATE)
) dt
ON a.ImportDate = dt.datum
WHERE a.unitytypeid = 12
UNION ALL
SELECT
b.Jahr
, b.UnityId
, a.UnityId
, b.Analytical_Code
, a.Unit_Code
, a.Unit_Name
, cast(case when a.Active = 'True' then 1 else 0 end as bit)
, a.Show_in_org_chart
, a.Begin_Date
, a.End_Date
, a.Unit_Owner_First_Name
, a.Unit_Owner_Last_Name
, a.Unit_Owner_Login
, a.Unit_Owner_CorporateID
, a.UnityParentId
, a.UnityTypeId
, a.Unit_Level
, a.Magnitude_Code
, a.ImportDate
, b.ReplicationLevel + 1
FROM [Staging_INPUT].[DBO].[OBS_Workunit] a
JOIN cte b
ON a.UnityId = b.UnityParentId
AND a.ImportDate = b.ImportDate
AND a.UnityTypeId >= 6
)
, Company
AS
(
SELECT DISTINCT
Jahr
, UnityId
, LEFT(REPLACE(Magnitude_Code,'XE','U'),4) CompanyUID
FROM cte
WHERE UnityTypeId = 7
AND Active = 1
)
, BUs
AS
(
SELECT DISTINCT
a.Jahr JAHR
, a.UnityId UnityId
, c.Analytical_Code BU_CODE
, c.Unit_Name BU_NAME
, b.CompanyUID
FROM cte a
JOIN Company b
ON a.Jahr = b.Jahr
AND a.UnityId = b.UnityId
AND a.Active = 1
JOIN cte c
ON a.Jahr = c.Jahr
AND a.UnityId = c.Unit_UnityId
AND c.Active = 1
WHERE ISNULL(c.Analytical_Code,'') != ''
)
SELECT DISTINCT
a.JAHR JAHR
, a.BU_CODE BU_CODE
, a.BU_NAME BU_NAME
, 'EUROPE\'
+ b.Unit_Owner_Login BU_LOGIN
, b.Unit_Owner_Last_Name
+ ', '
+ b.Unit_Owner_First_Name BU_LOGIN_NAME
, a.CompanyUID COMPANY_UID
FROM BUs a
JOIN cte b
ON a.Jahr = b.Jahr
AND a.UnityId = b.UnityId
AND b.Active = 1
UNION
SELECT DISTINCT
a.Jahr JAHR
, a.BU_CODE BU_CODE
, a.BU_NAME BU_NAME
, c.BU_LOGIN BU_LOGIN
, c.BU_LOGIN_NAME BU_LOGIN_NAME
, a.CompanyUID COMPANY_UID
FROM BUs a
CROSS JOIN (
SELECT DISTINCT
[Last Name] COLLATE Latin1_General_100_CI_AS
+ ', '
+ [First Name] COLLATE Latin1_General_100_CI_AS BU_LOGIN_NAME
, 'EUROPE\'
+ [User Id] COLLATE Latin1_General_100_CI_AS BU_LOGIN
FROM NAVISION.dbo.Employee
WHERE [Global Dimension 2 Code] IN (
10061
, 10062
)
AND ISNULL([User Id],'') != ''
) c
GO
执行时间和统计数据:
use NAVISION
GO
set statistics io on
set statistics time on
select *
from NAVISION.dbo.UnitLoginHistory
where Jahr = 2017
order by 1,2
SQL Server解析和编译时间: CPU时间= 0 ms,经过时间= 0 ms。
(34119行受影响) 表'工作台'。扫描计数1607,逻辑读取253696,物理读取0,预读读取1238,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U415 Altran Engineering GmbH $ Employee'。扫描计数1,逻辑读取128,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U388 Altran Aviation GmbH $ Employee'。扫描计数1,逻辑读取42,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U354 Altran Service GmbH $ Employee'。扫描计数1,逻辑读取210,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U353 AIH Holding GmbH Co KG $ Employee'。扫描计数1,逻辑读取934,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'OBS_Workunit'。扫描计数46286,逻辑读取10430933,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。
SQL Server执行时间: CPU时间= 1363546毫秒,已用时间= 1455980毫秒。
use Staging_INPUT
GO
set statistics io on
set statistics time on
select *
from NAVISION.dbo.UnitLoginHistory
where Jahr = 2017
order by 1,2
SQL Server解析和编译时间: CPU时间= 0 ms,经过时间= 0 ms。
(34119行受影响) 表'工作台'。扫描计数582,逻辑读取576096,物理读取0,预读取读取146,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'工作文件'。扫描计数0,逻辑读取0,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'OBS_Workunit'。扫描计数53573,逻辑读取485656,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U415 Altran Engineering GmbH $ Employee'。扫描计数1,逻辑读取128,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U388 Altran Aviation GmbH $ Employee'。扫描计数1,逻辑读取42,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U354 Altran Service GmbH $ Employee'。扫描计数1,逻辑读取210,物理读取0,预读取读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。 表'U353 AIH Holding GmbH Co KG $ Employee'。扫描计数1,逻辑读取934,物理读取0,预读读取0,lob逻辑读取0,lob物理读取0,lob预读读取0。
SQL Server执行时间: CPU时间= 15047 ms,经过时间= 28007 ms。
答案 0 :(得分:0)
不同的性能必须归因于不同的执行计划。由于计划因数据库环境而异,因此这表明了影响计划的不同设置。有许多默认的SET选项和属性可能因数据库而异,您错过了一两个。
我建议为2个数据库生成CREATE DATABASE
脚本并比较脚本。
修改强>
database compatibility level设置的差异会影响执行计划。对于110(SQL Server 2012)级别的数据库,SQL Server将使用旧的基数估算器,而除非打开LEGACY_CARDINALITY_ESTIMATION数据库作用域设置,否则较新的CE将用于120及更高版本的数据库。