今天在对服务代理问题进行故障排除时,我发现数据库所有者是离开公司的员工的 Windows 登录名。他的登录名已被删除,因此查询通知失败。
据说处理这个问题的最佳实践是让“sa”成为数据库所有者。我们更改了它并清除了队列。
我的(非常基本的)问题:数据库所有者是什么,其目的是什么?
我有两个 SQL 代理作业,它们计划以不同的时间间隔运行。第一个作业每天运行一次完整备份。第二个作业每十五分钟运行一次事务日志备份。
随着数据库的增长,完整备份的时间比原计划的要长(即使有压缩)。我从我的日志中注意到事务日志备份现在同时运行。
我是否应该更改事务日志备份的计划,以便在运行完整备份时不运行?有关系吗?
BOL 中的建议相当模糊:
根据需要经常备份 master 以充分保护数据以满足您的业务需求。我们建议定期备份计划,您可以在大量更新后补充额外的备份。
如果你进一步冒险,你会发现这些细节:
导致 master 更新和需要进行备份的操作类型包括以下内容:
- 创建或删除用户数据库。
- 如果用户数据库自动增长以容纳新数据,
master 不会受到影响。- 添加或删除文件和文件组。
- 添加登录或其他与登录安全相关的操作。
- 数据库安全操作,例如向数据库添加用户,不影响master。
- 更改服务器范围或数据库配置选项。
- 创建或删除逻辑备份设备。
- 为分布式查询和远程过程调用 (RPC) 配置服务器,例如添加链接服务器或远程登录。
因此,如果我们所有的登录都是通过 Windows 组添加的,并且我们不对数据库进行任何其他更改,这是否意味着对 master 进行一次备份就足够了?
如果不是,master 数据库的标准备份间隔是多少?
我试图理解为什么使用表变量会阻止优化器使用索引查找然后书签查找与索引扫描。
填充表:
CREATE TABLE dbo.Test
(
RowKey INT NOT NULL PRIMARY KEY,
SecondColumn CHAR(1) NOT NULL DEFAULT 'x',
ForeignKey INT NOT NULL
)
INSERT dbo.Test
(
RowKey,
ForeignKey
)
SELECT TOP 1000000
ROW_NUMBER() OVER (ORDER BY (SELECT 0)),
ABS(CHECKSUM(NEWID()) % 10)
FROM sys.all_objects s1
CROSS JOIN sys.all_objects s2
CREATE INDEX ix_Test_1 ON dbo.Test (ForeignKey)
Run Code Online (Sandbox Code Playgroud)
使用单个记录填充表变量,并尝试通过搜索外键列来查找主键和第二列:
DECLARE @Keys TABLE (RowKey INT NOT NULL)
INSERT @Keys (RowKey) VALUES (10)
SELECT
t.RowKey,
t.SecondColumn
FROM
dbo.Test t
INNER JOIN
@Keys k
ON
t.ForeignKey = …Run Code Online (Sandbox Code Playgroud) sql-server optimization sql-server-2008-r2 user-defined-table-type bookmark-lookup
根据我的分析,我们数据仓库的完整维度模型需要从 200 多个源表中提取。其中一些表将作为增量加载的一部分提取,而其他表将作为完整加载。
需要注意的是,我们有大约 225 个具有相同架构的源数据库。
据我所知,在 SSIS 中构建一个带有 OLE DB 源和 OLE DB 目标的简单数据流需要在设计时确定列和数据类型。这意味着我最终会得到 200 多个数据流,仅用于提取。
从可维护性的角度来看,这对我来说是一个大问题。如果我需要对提取代码进行某种彻底的更改,我将不得不修改 200 个不同的数据流。
另一种选择是,我编写了一个小脚本,用于读取我想从一组元数据表中提取的源数据库、表名和列。代码在多个循环中运行,并使用动态 SQL 通过链接服务器和 OPENQUERY 从源表中提取。
根据我的测试,这仍然不如使用带有 OLEDB 源和目标的 SSIS 数据流快。所以我想知道我有什么样的选择。到目前为止的想法包括:
解决这个问题的最佳方法是什么?当谈到 .NET 编程时,我是一个初学者,所以仅仅学习基础知识所需的时间也是一个问题。
我在AdventureWorks2012数据库中运行此查询:
SELECT
s.SalesOrderID,
d.CarrierTrackingNumber,
d.ProductID,
d.OrderQty
FROM Sales.SalesOrderHeader s
JOIN Sales.SalesOrderDetail d
ON s.SalesOrderID = d.SalesOrderID
WHERE s.CustomerID = 11077
Run Code Online (Sandbox Code Playgroud)
如果我查看估计的执行计划,我会看到以下内容:

初始索引查找(右上角)使用 IX_SalesOrderHeader_CustomerID 索引并搜索文字 11077。它估计有 2.6192 行。

如果我使用DBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAM,则显示值 11077 介于两个采样键 11019 和 11091 之间。

11019 和 11091 之间不同行的平均数为 2.619718,或四舍五入为 2.61972,这是为索引查找显示的估计行的值。
我不明白的部分是针对 SalesOrderDetail 表的聚集索引查找的估计行数。

如果我运行DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID'):

所以 SalesOrderID(我正在加入)的密度是 3.178134E-05。这意味着 1/3.178134E-05 (31465) 等于 SalesOrderDetail 表中唯一 SalesOrderID 值的数量。
如果 SalesOrderDetail 中有 31465 个唯一的 SalesOrderID,那么在均匀分布的情况下,每个 SalesOrderID 的平均行数为 121317(总行数)除以 31465。平均值为 3.85561
因此,如果估计要循环的行数是 …
sql-server optimization execution-plan sql-server-2012 cardinality-estimates query-performance
有许多博客文章和最佳实践文章颂扬将 SQL Server 数据文件放在一个硬盘驱动器上并将事务日志放在另一个硬盘驱动器上的优点。给出的原因是数据库文件将经历随机读取和写入,而事务日志将只有顺序写入。
但是,如果您有数百个数据库呢?将数百个事务日志文件放在一个单独的磁盘上是否有真正的性能优势?如果要写入多个事务日志,那么我认为事务日志写入与数据库写入一样随机。
我正在使用从 MS Access 导入的旧数据库。在 MS Access > SQL Server 升级过程中创建了大约 20 个带有非集群唯一主键的表。
其中许多表还具有唯一的非聚集索引,它们是主键的副本。
我正在尝试清理它。
但是我发现在我将主键重新创建为聚集索引,然后尝试重建外键后,外键引用了旧的重复索引(这是唯一的)。
我知道这一点,因为它不会让我删除重复的索引。
我认为 SQL Server 会始终选择一个主键,如果存在的话。SQL Server 是否有在唯一索引和主键之间进行选择的方法?
要复制问题(在 SQL Server 2008 R2 上):
IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Child') DROP TABLE Child
GO
IF EXISTS (SELECT * FROM sys.tables WHERE name = 'Parent') DROP TABLE Parent
GO
-- Create the parent table
CREATE TABLE Parent (ParentID INT NOT NULL IDENTITY(1,1))
-- Make the parent table a heap
ALTER TABLE Parent ADD …Run Code Online (Sandbox Code Playgroud) 我正在使用一个旧数据库,该数据库已针对名为ColorList的表实现了查询通知。
在为不相关的问题运行服务器端跟踪时,我注意到查询
SELECT color FROM ColorList
Run Code Online (Sandbox Code Playgroud)
每 10 毫秒执行一次。
这是查询通知的工作方式吗?SQL Server 是否存储原始查询的结果,然后无休止地运行查询,直到检测到更改?
根据我的阅读,基于订单标题/行项目结构的事实表的推荐粒度是在行项目级别。在此过程中,任何仅适用于订单标题的附加值都会为每个行项目重复:
下面(来自第二个链接)是这种设计的一个例子:

在此示例中,适用于整个订单的运费对每个订单项重复。
但是,如果您将所有运输金额归结到特定客户下,您的实际价值就会翻倍。您如何避免这种价值翻倍?
sql-server ×9
backup ×2
optimization ×2
etl ×1
facttable ×1
hardware ×1
index ×1
permissions ×1
primary-key ×1
ssis ×1