Avi's questions

我有一个大的事实表和一个简单星型模式中的小得多的维度表：

--1.
CREATE TABLE dbo.Dim
(
Id INT NOT NULL IDENTITY PRIMARY KEY CLUSTERED,
CustomerName VARCHAR(2000)
)
--index
CREATE UNIQUE NONCLUSTERED INDEX uniqueindex1 ON Dim(CustomerName);


--2. 
CREATE TABLE dbo.Fact
(
...
PurchaseDate DATE 
CustomerNameId INT CONSTRAINT fk1 FOREIGN KEY (CustomerNameId) REFERENCES dbo.Dim(Id)
...
)
--index
CREATE CLUSTERED COLUMNSTORE INDEX ccs ON dbo.Fact;

运行以下简单查询，过滤事实表并加入维度：

SELECT sd.CustomerName,f.*
FROM dbo.Fact f
INNER JOIN dbo.Dim sd ON sd.Id = f.CustomerNameId
WHERE f.PurchaseDate IN (
'20000506',
'20000507',
'20000508',
'20000509',
'20000501',
'20000502',
'20000503'
)

我们得到以下丑陋的查询计划：

有趣的是，维度表倾向于在 4 次迭代中扫描所有 500 000 行，但最终在事实表的该日期范围内只需要几千行。

这对于较大的维度表来说是非常低效的，基本上所有的行都是一直扫描的，就像查找表索引甚至不存在一样。

预期的事情是sql server首先将事实表限制在日期范围内，然后使用这个有限的CustomerKeyId范围，它使用索引查找从小维度表中查找CustomerName。

1. 这真的是星型模式的效率低下，还是我在这里想念什么？
2. 换句话说，我怎么能强制 sql server 准备有限的 CustomerKeyId 表并只查找那些？（不知何故有CTE？）

我有几个数据库模式，如 [ext]、[stag] 等，当然还有内置的 [dbo] 模式，还有一个名为 [MyRole] 的角色。

我的计划是将 [MyRole] 添加到 DDL_ADMIN 角色，以便他们可以在所有模式中创建、更改、删​​除对象，但我希望阻止他们在 [dbo] 模式中完全这样做。

DDL_ADMIN 内置角色为其成员提供以下权限：

ALTER ANY ASSEMBLY                    
ALTER ANY ASYMMETRIC KEY              
ALTER ANY CERTIFICATE                 
ALTER ANY CONTRACT                    
ALTER ANY DATABASE DDL TRIGGER        
ALTER ANY DATABASE EVENT NOTIFICATION 
ALTER ANY DATASPACE                   
ALTER ANY FULLTEXT CATALOG            
ALTER ANY MESSAGE TYPE                
ALTER ANY REMOTE SERVICE BINDING      
ALTER ANY ROUTE                       
ALTER ANY SCHEMA                      
ALTER ANY SERVICE                     
ALTER ANY SYMMETRIC KEY               
CHECKPOINT                            
CREATE AGGREGATE                      
CREATE DEFAULT                        
CREATE FUNCTION                       
CREATE PROCEDURE                      
CREATE QUEUE                          
CREATE RULE                           
CREATE SYNONYM                        
CREATE TABLE                          
CREATE TYPE                           
CREATE VIEW                           
CREATE XML SCHEMA COLLECTION          
REFERENCES                            

由于 DENY 优先于 GRANT，因此我可以在[MyRole]的dbo模式上拒绝完全相同的权限。

它应该很简单：

DENY ALTER ANY ASSEMBLY                    ON SCHEMA::dbo TO MyRole
DENY ALTER ANY ASYMMETRIC KEY              ON SCHEMA::dbo TO MyRole
DENY ALTER ANY CERTIFICATE                 ON SCHEMA::dbo TO MyRole
DENY ALTER ANY CONTRACT                    ON SCHEMA::dbo TO MyRole
DENY ALTER ANY DATABASE DDL TRIGGER        ON SCHEMA::dbo TO MyRole
DENY ALTER ANY DATABASE EVENT NOTIFICATION ON SCHEMA::dbo TO MyRole
DENY ALTER ANY DATASPACE                   ON SCHEMA::dbo TO MyRole
DENY ALTER ANY FULLTEXT CATALOG            ON SCHEMA::dbo TO MyRole
DENY ALTER ANY MESSAGE TYPE                ON SCHEMA::dbo TO MyRole
DENY ALTER ANY REMOTE SERVICE BINDING      ON SCHEMA::dbo TO MyRole
DENY ALTER ANY ROUTE                       ON SCHEMA::dbo TO MyRole
DENY ALTER ANY SCHEMA                      ON SCHEMA::dbo TO MyRole
DENY ALTER ANY SERVICE                     ON SCHEMA::dbo TO MyRole
DENY ALTER ANY SYMMETRIC KEY               ON SCHEMA::dbo TO MyRole
DENY CHECKPOINT                            ON SCHEMA::dbo TO MyRole
DENY CREATE AGGREGATE                      ON SCHEMA::dbo TO MyRole
DENY CREATE DEFAULT                        ON SCHEMA::dbo TO MyRole
DENY CREATE FUNCTION                       ON SCHEMA::dbo TO MyRole
DENY CREATE PROCEDURE                      ON SCHEMA::dbo TO MyRole
DENY CREATE QUEUE                          ON SCHEMA::dbo TO MyRole
DENY CREATE RULE                           ON SCHEMA::dbo TO MyRole
DENY CREATE SYNONYM                        ON SCHEMA::dbo TO MyRole
DENY CREATE TABLE                          ON SCHEMA::dbo TO MyRole
DENY CREATE TYPE                           ON SCHEMA::dbo TO MyRole
DENY CREATE VIEW                           ON SCHEMA::dbo TO MyRole
DENY CREATE XML SCHEMA COLLECTION          ON SCHEMA::dbo TO MyRole
DENY REFERENCES                            ON SCHEMA::dbo TO MyRole
GO

SQL Server 对以上所有内容都说“DENY ALTER ...附近的语法不正确”。

我试图从 BOL 中拼出正确的语法，但只能想出：

DENY ALTER ON SCHEMA::dbo TO MyRole;

没有其他的。

拒绝 DDL_ADMIN 成员资格向 [MyRole] 成员提供的所有权限的最简单方法是什么，但仅限于 [dbo] SCHEMA？

谢谢！

聚集列存储索引表通常对大型表很有用。理想情况下有数百万行。对查询也很有用，它只选择此类表中可用列的子集。

如果我们打破这两个“规则”/最佳实践会发生什么？

1. 就像拥有一个聚集列存储索引表，它最多只能存储几千或几十万行。
2. 并针对需要所有列的那些聚集列存储表运行查询。

与行存储聚集索引表相比，我的测试没有显示任何性能下降。这对我们来说很棒。

是否存在违反这两条规则的“长期”影响？还是任何尚未出现的隐藏陷阱？

上下文为什么需要它：我设计了一个数据库模型，它将用于不同供应商数据库的许多实例。每个数据库中的模式都保持不变，但不同的供应商有不同的数据量。因此，很少有小型供应商最终可能会在其表中包含少量数据（<1 000 000）。我不能让自己为行存储和列存储模型保留两个不同的数据库。

我有一个包含数百万行的大型事实表，称为 MyLargeFactTable，它是一个聚集列存储表。

那里也有一个复合主键约束（customer_id、location_id、order_date 列）。

我还有一个临时表#my_keys_to_filter_MyLargeFactTable，具有完全相同的 3 列，它包含这 3 个键值的几千个唯一组合。

下面的查询给了我想要的结果集

...
FROM #my_keys_to_filter_MyLargeFactTable AS t
JOIN dbo.MyLargeFactTable AS m
ON m.customer_id = t.customer_id
AND m.location_id = t.location_id
AND m.order_date = t.order_date

但我注意到事实表上的索引扫描运算符返回的行数超过了它应该返回的行数（大约一百万）并将其输入过滤器运算符，这进一步将结果集减少到所需的几千行。

索引扫描运算符读取大量行（它们非常宽的行）增加 IO，并显着减慢整个查询。

我的参数不是 sargable 吗？

如何删除过滤器运算符并以某种方式强制索引扫描运算符只读取几千行？

表定义：

create table #my_keys_to_filter_MyLargeFactTable 
(
customer_id varchar(96) not null,
location_id varchar(96) not null,
order_date date not null,
primary key clustered (customer_id,location_id,order_date)
)

create table MyLargeFactTable
(
customer_id varchar(96) not null,
location_id varchar(96) not null,
order_date date not null,
...
lot of wide decimal typed columns, and even large varchars
...
PRIMARY KEY NONCLUSTERED  (customer_id,location_id,order_date),
INDEX cci CLUSTERED COLUMNSTORE
)

我有带有复合非聚集索引的大型事实表，如下所示：

NONCLSUTERED INDEX (OrderDate,OrderType,ClientKey,ItemKey,CustomerKey)

以“Key”结尾的列是 varchar(50) 列，但它们存储 20-30 个字符的字符串。

从长远来看，我是否需要担心索引中的 varchar 列的长度实际上是不同的？当数百万行合并到这些表中时，我会得到更多的页面拆分、更慢的性能吗？ https://stackoverflow.com/questions/59667/what-are-the-use-cases-for-selecting-char-over-varchar-in-sql

由于列的长度不同，Sql Server 引擎是否更难使用该索引找出计划？我读到 CHAR 更好，因为它的大小固定，并且 db 引擎更容易计算，因此它的性能更好。有那么重要吗？

使用 SHA2_256 函数单独散列这些“Key”列是否值得，所以它们变成固定大小的 BINARY(32)？

NONCLSUTERED INDEX (OrderDate,OrderType,HASHEDClientKey,HASHEDItemKey,HASHEDCustomerKey)

我做了我的测试，至少回答了性能问题，并且没有看到哈希键比 varchar 有任何性能优势。事实上，计算哈希并将每个额外的 32 个字节存储在原始“Key”列旁边是一个很大的开销。

我无法测试的是，当我每天将数百万行合并到表中时，这些 varchar 索引将如何表现？

从性能和维护的角度来看，您会选择哪一个？

我计划每月沿日期列对我的表进行分区，并在几个地方阅读过，建议（实际上是最佳实践）在范围的两个“末端”都保留空分区。 https://techcommunity.microsoft.com/t5/premier-field-engineering/oops-i-forgot-to-leave-an-empty-sql-table-partition-how-can-i/ba-p/370563

作为一种天真的方法，我会像这样创建我的分区函数：

CREATE PARTITION FUNCTION MyPf(DATE)
AS RANGE RIGHT FOR VALUES (
'1900-01-01',
'2019-10-01','2019-11-01',...,...,...,'2022-08-01',
'9999-12-31');

CREATE PARTITION SCHEME MyPs AS PARTITION MyPf
ALL TO (MySingleFileGroup)

我可以保证不会将早于2019-10-01的数据插入到表中，并且我计划在到达2022-08-01后保留 SPLIT 分区，并一直这样做直到9999-12-31。我还计划定期截断旧分区并合并旧分区范围。

我是否错过了有关此设置的最佳实践的任何明显内容？我唯一的目标是能够在不移动数据的情况下进行拆分和合并。

谢谢！

我有一个简单恢复模式的数据库，并定期进行 FULL、DIFF 备份。

这个数据库也有每个月的文件组。每个文件组只有一个 NDF 文件。

像这样：

FileGroup: PRIMARY
File: Primary.mdf

FileGroup: FG201801
File: 201801.ndf

FileGroup: FG201802
File: 201802.ndf

FileGroup: FG201803
File: 201803.ndf

etc

我的目标是双重的：

1. 能够对每个分区级别进行备份。当我将文件组标记为只读时，我只能阅读它。所以我已经分离了部分备份 BAK 文件。 https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/partial-backups-sql-server

2. 第二个目标是（我的问题在这里），能够只恢复一个文件组，而不恢复 PRIMARY 文件组或触及任何其他文件组。

甚至可能吗？

据了解，如果我只想恢复假设 FG201802 ，而不影响 PRIMARY 和其他人，那么首先我必须恢复包含 PRIMARY 文件组的完整备份，然后我可以恢复 FG201802 的部分备份。如何在不恢复 PRIMARY 的情况下恢复 FG201802？

任何人都可以向我指出一个在线资源来证明这一点吗？网络上的所有文章（我发现）总是开始恢复 PRIMARY 完整备份，然后一一应用其余的部分备份。

我只希望恢复部分备份，怎么办？

谢谢！

活动监视器可以实时显示服务器上的整体 IO 性能（以 MBytes/s 为单位），但不能显示每个会话级别的相同信息。

我知道 DMV 和 sp_who2 来检索会话级别的 io 消耗，但是在那里，它只能提取读取/写入的数量，而不是实际的兆字节/秒。

如何查看以 MBytes/s 为单位的实时会话级 io 性能？

目前，这些更新适用于 SQL Server 2014：

1. SQL Server 2014 SP1 CU2
2. SQL Server 2014 SP1 CU1
3. SQL Server 2014 SP1

如果我想做一个滑流安装：

仅下载 #1 并使用它进行滑流安装就足够了吗？

或者我应该下载#3，然后进行滑流安装，然后应用#1？