标签: sql-server

考虑这个由N自连接组成的查询：

select
    t1.*
from [Table] as t1
join [Table] as t2 on
    t1.Id = t2.Id
-- ...
join [Table] as tN on
    t1.Id = tN.Id

它生成一个执行计划，其中包含 N 次聚集索引扫描和 N-1 次合并连接。

老实说，我看不出有任何理由不优化所有连接并仅执行一次聚集索引扫描，即将原始查询优化为：

select
    t1.*
from [Table] as t1

问题

• 为什么连接没有被优化掉？
• 说每个连接都不会改变结果集在数学上是不正确的吗？

测试：

• 源服务器版本：SQL Server 2014 (12.0.4213)
• 源数据库引擎版：Microsoft SQL Server 标准版
• 源数据库引擎类型：独立 SQL Server
• 兼容级别：SQL Server 2008 (100)

查询没有意义；它刚刚出现在我的脑海中，我现在对它很好奇。

这是表创建和 3 个查询的小提琴：使用inner join's、使用left join's 和混合。您也可以在那里查看执行计划。

似乎left join在结果执行计划中消除了inner joins而s 则没有。不过还是不明白为什么 …

我正在尝试备份 TDE 数据库的主密钥，但 SQL Server 说没有。这有点奇怪，但我确定我只是做错了什么。我是服务器上的系统管理员，所以我应该能够看到所有内容。

这是失败的声明：

USE [my_db];
BACKUP MASTER KEY
TO FILE = 'C:\master_key'
ENCRYPTION BY PASSWORD = 'some_killer_password';

并返回错误消息：

消息 15151，级别 16，状态 1，第 11 行
找不到对称密钥“主密钥”，因为它不存在或您没有权限。

我已使用以下内容查看有关数据库加密密钥和关联证书的详细信息，但是sys.certificates表中的证书详细信息为空。

USE [my_db];
SELECT DatabaseName = d.name
    , ddek.encryptor_type
    , ddek.opened_date
    , c.name
    , c.cert_serial_number
    , c.pvt_key_encryption_type_desc
    , c.subject
FROM sys.dm_database_encryption_keys ddek
    INNER JOIN sys.databases d ON ddek.database_id = d.database_id
    LEFT JOIN sys.certificates c ON ddek.encryptor_thumbprint = c.thumbprint
WHERE d.name <> 'tempdb' /* tempdb is auto-encrypted by SQL Server …

我读到 SQL Server 2017 现在将包含 PowerBI Server。他们还将 SSRS 移动到不同的安装程序，因此它不会打包在原始 SQL Server 安装中。这是否意味着微软最终会尝试弃用 SSRS？我们的团队是否应该尝试在 PowerBI 中构建新报告并转换以前的 SSRS 报告？

如果我使用ntext、text或image数据类型对表进行分区并使用 重建单个分区上的索引online = off，这会锁定整个表还是仅锁定有问题的分区？

谈论“LOB”和“二进制”数据时有什么区别？

就二进制数据存储在单独的文件组中而言，它是相同的，还是存在差异？

我正在与一位同事合作，他建议将我们的 1 个实例数据库拆分为大约 7 个数据库（按数据域划分）用于开发和 7 个相同的数据库用于生产。我得到了测试生产二元性逻辑，但是在什么情况下或将我们的 1 个相对简单的数据库拆分为 7 个数据库有什么优势？我们的数据仓库仅由一个商业智能应用程序消耗/使用，期间。

我很关心这个方向，所以希望你能讨论提出这个拆分的一般原因，我可以给你一个数据库当前属性的概要。

1 个数据库数据仓库：总共 352 GB，203 个表，170 个视图

建议拆分：

A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined

正如您所看到的，就提议的好处而言，这已经是一个令人头疼的问题，因为存储甚至不会远程平均分配，80% 还留在 1 个数据库上。显然，按架构对我们的数据库进行分区是不可能的（从硬件角度来看），因为我们没有企业级 SQL Server。

给出的拆分原因：

1. 当前的数据库优化不佳，文档很少，数据类型次优，索引次优。

我的菜鸟想法：这些问题不是和数据库拆分无关吗？它们只是需要以任何方式自行解决的问题。

2. 当前数据库中有 372 个对象，这使它变慢。

我的想法：在我看来，这似乎并不大。

3. 一个数据库比 7 个数据库更难记录和绘制模式图（我们将拥有跨越多个数据库的视图）。

我的想法： .... 这对我来说似乎完全荒谬，但也许我错了。我们已经按照 13 个“源系统”模式组织了我们的数据仓库。

4. 一个数据库会导致更多的数据库死锁。

-- 这个问题不是也和多数据库完全无关吗？我的理解是死锁发生在表级别（实际上通常甚至只是行级别，但是呃）。即便如此，我们所有的数据插入都发生在午夜，我们所有下游到 BI 的选择发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，是不是（死锁会发生）？另外，我个人没有看到在正常操作期间发生表死锁的证据。

5. 数据库技术所有权/所有权。

只有我们两个人在数据库上工作。他有可能真的想隔离我们的“封地”。真的，这不是问题，但无论如何不能在架构级别确定用户权限吗？

将数据仓库拆分为多个数据库的正当理由是什么？

很想在这里进一步了解一般的数据库。是的，我碰巧在我的知识空白处做了很多工作，但这份工作就是它，我一直在努力。到目前为止，东西一直很好用（敲木头）。

我在 2014 年有 20 个听众，大约有 500 个 DBS，

以最少的停机时间和精力来迁移这些的最佳方法是什么

我的想法是：停止访问备份 dbs 开始恢复 dbs 在恢复运行时：在 2014 年删除 AOG 在 2016 年创建它完成

这看起来很简单，但是对于 TB 数据，这需要一些时间。

找到了这个 -> 从 2014 年到 2016 年升级 AlwaysOn AG 的推荐方法 但它也没有解释

希望有人能帮忙

当我将新数据库添加到我们的开发服务器（使用 SSMS）时，它会自动创建 5 个表。

这些是已存在于另一个数据库中的应用程序表的副本。

我假设这是最近的一些 SQL Server 功能，我不知道在哪里可以将表标记为“通用”或诸如此类，因此会自动添加到新数据库中。

但是我怎样才能阻止它发生呢？

为避免混淆，此数据库未编写脚本，而是直接从 SSMS GUI 创建（右键单击数据库 > 新建数据库）

（移自 StackOverflow）

当我在 SSDT 数据库项目中包含登录名和用户并尝试使用“数据库偏离注册版本时阻止发布”选项部署 DACPAC 时，即使没有任何更改，它也始终会检测到数据库用户的漂移。

例如，我将项目发布到以前不存在数据库的新服务器上，并且一切正常。正确创建了登录名和用户等。然后我立即将同一个项目发布到同一个服务器上，部署被阻止，因为 db 用户已经漂移。但是我没有对 SQL 实例进行任何更改，甚至没有更新项目。

如果我从 SSDT 项目中删除登录名和用户，那么一切都会按预期进行，即我不会从漂移检测中得到误报，并且我可以更新和部署其他类型的对象而不会出错。

这是登录和用户的脚本：

CREATE LOGIN AppAcct WITH PASSWORD = 'Password1';
GO

CREATE USER AppAcct FOR LOGIN AppAcct
    WITH DEFAULT_SCHEMA = dbo;
GO

GRANT CONNECT TO AppAcct;
GO

这是我正在使用的发布配置文件：

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <IncludeCompositeObjects>True</IncludeCompositeObjects>
    <TargetDatabaseName>DacpacDrift</TargetDatabaseName>
    <DeployScriptFileName>DacpacDrift.sql</DeployScriptFileName>
    <TargetConnectionString>Data Source=.\dev14;Integrated Security=True;Pooling=False</TargetConnectionString>
    <BlockWhenDriftDetected>True</BlockWhenDriftDetected>
    <RegisterDataTierApplication>True</RegisterDataTierApplication>
    <ProfileVersionNumber>1</ProfileVersionNumber>
    <ScriptDatabaseOptions>True</ScriptDatabaseOptions>
    <BlockOnPossibleDataLoss>True</BlockOnPossibleDataLoss>
    <DropObjectsNotInSource>True</DropObjectsNotInSource>
  </PropertyGroup>
</Project>

这就是漂移报告的样子：

<?xml version="1.0" encoding="utf-8"?>
<DriftReport xmlns="http://schemas.microsoft.com/sqlserver/dac/DriftReport/2012/02">
  <Additions />
  <Removals />
  <Modifications>
    <Object Name="[AppAcct]" Parent="" Type="SqlUser" />
  </Modifications>
</DriftReport> …

如果我有一个 cte，例如下面的代码。表 People 被查询多少次？我的印象是它只被调用了 1 次并存储在内存中，但我一直在运行的一些查询似乎运行的时间比它们应该的要长得多。这让我相信它可能会击中 People Table 3 次。

with ctegeneric as (select person from people where person = 'dumb')
Select * from ctegeneric 
UNION ALL
Select * from ctegeneric 
UNION ALL
Select * from ctegeneric