小编Sol*_*zky的帖子

我找了实际指导的设定值BUFFERCOUNT，BLOCKSIZE以及MAXTRANSFERSIZE该的BACKUP命令。我做了一些研究（见下文），我做了一些测试，我完全意识到任何真正有价值的答案都会以“好吧，这取决于……”开头。我对我所做的测试以及我发现的任何资源中显示的测试（见下文）的担忧是，测试是在真空中完成的，很可能是在没有其他负载的系统上完成的。

我很好奇关于这三个基于长期经验的选项的正确指导/最佳实践：数周或数月内的许多数据点。而且我不是在寻找特定值，因为这主要是可用硬件的功能，但我想知道：

• 各种硬件/负载因素如何影响应该做什么。
• 是否存在不应覆盖这些值中的任何一个的情况？
• 是否存在覆盖任何不明显的陷阱？使用了太多内存和/或磁盘 I/O？恢复操作复杂吗？
• 如果我有一台运行多个 SQL Server 实例的服务器（一个默认实例和两个命名实例），并且如果我同时运行所有 3 个实例的备份，这是否会影响我设置这些值的方式，而不是确保集体（BUFFERCOUNT* MAXTRANSFERSIZE) 不超过可用 RAM？可能的 I/O 争用？
• 在同一台服务器上拥有三个实例并再次同时运行所有三个实例的备份的相同场景中，在每个实例中同时运行多个数据库的备份如何影响这些值的设置？这意味着，如果三个实例中的每一个都有 100 个数据库，则每个实例同时运行 2 或 3 个备份，这样就有 6 到 9 个备份同时运行。（在这种情况下，我有许多中小型数据库，而不是一些大型数据库。）

到目前为止我收集到的：

• BLOCKSIZE：

  • 支持的大小为 512、1024、2048、4096、8192、16384、32768 和 65536 (64 KB) 字节。^[1]
  • 磁带设备的默认值为 65536，否则为 512 ^[1]
  • 如果您要进行备份并计划从 CD-ROM 复制和恢复，请指定 BLOCKSIZE=2048 ^[1]
  • 写入单个磁盘时，默认512就可以了；如果使用RAID阵列或SAN，则必须测试以查看默认或65536是否更好。^{[13（第 18 页）]}

  • 如果手动设置，该值需要 >= 用于创建数据文件的块大小，否则您将收到以下错误：

    消息 3272，级别 16，状态 0，第 3 行
    “C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\BackupTest.bak”设备的硬件扇区大小为 4096，但块大小参数指定不兼容的覆盖值 512。使用兼容的块大小重新发出语句。 …

首先要做的事情是：我将 MS SQL Server 2008 与兼容级别为 80 的数据库一起使用，并使用 .Net 的System.Data.SqlClient.SqlConnection.

出于性能原因，我创建了一个索引视图。因此，视图中引用的表的更新需要使用ARITHABORT ON. 但是，探查器显示 SqlClient 正在连接ARITHABORT OFF，因此对这些表的更新失败。

是否有使 SqlClient 使用的中央配置设置ARITHABORT ON？我能找到的最好方法是在每次打开连接时手动执行该操作，但是更新现有代码库以执行此操作将是一项相当大的任务，因此我很想找到更好的方法。

我刚刚听说mysqlpump - 看起来它是与 MySQL 5.7 一起发布的，但是 MySQL 5.7 仍然包含mysqldump。它们都是备份程序，但谁能总结一下主要区别？是否存在其中之一可能更好地工作的场景？mysqldump 会被 mysqlpump 淘汰吗？

已经有很多关于SQL Server中标量 UDF的危险的文章。随意搜索将返回大量结果。

不过，有些地方标量 UDF 是唯一的选择。

例如：处理 XML 时：XQuery 不能用作计算列定义。Microsoft 记录的一种选择是使用标量 UDF将 XQuery 封装在标量 UDF 中，然后在计算列中使用它。

这会产生各种影响和一些解决方法。

• 查询表时逐行执行
• 强制对表的所有查询串行运行

您可以通过对函数进行架构绑定来绕过逐行执行，并保留计算列或对其进行索引。即使未引用标量 UDF，这两种方法都不能阻止强制序列化查询表。

有没有一种已知的方法可以做到这一点？

我习惯于在非常安全的环境中工作，因此我将权限设计为非常精细的粒度。我通常做的一件事是明确地为DENY用户提供UPDATE永远不应该更新的列的能力。

例如：

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

一旦设置了值，就不应更改这两列。因此，我明确DENY了UPDATE他们的权限。

最近，在一次团队会议上，一位开发人员提出了一个观点，即确保字段永远不会更新的逻辑应该包含在应用程序层而不是数据库层中，以防“他们出于某种原因需要更新值”。对我来说，这听起来像是典型的开发人员心态（我知道，我曾经是其中之一！）

我是我公司的高级架构师，我一直遵循让应用程序运行所需的最少权限的原则。所有权限都会定期审核。

这种情况下的最佳实践是什么？

我正在通过源服务器上的视图从链接服务器查询数据。该视图必须包含几个标准化列，例如Created,Modified和Deleted，但在这种情况下，源服务器上的表没有任何合适的信息。因此，列被显式转换为它们各自的类型。我更新了视图，从

NULL AS Modified

到

CAST(NULL as DateTime) as Modified

但是，执行此更新后，视图会触发以下错误消息：

消息 7341，级别 16，状态 2，第 3 行无法从链接服务器“”的 OLE DB 提供程序“SQLNCLI11”获取列“（用户生成的表达式）。Expr1002”的当前行值。

我们已经在源服务器上完成了这种“显式转换” - 无需担心，我怀疑这个问题可能与所涉及的服务器版本有关。我们真的不需要应用这个演员表，但感觉更干净。现在我只是好奇为什么会发生这种情况。

服务器版本（来源）：

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 2014 年 5 月 14 日 18:34:29 版权所有 (c) Microsoft Corporation Enterprise Edition（64 位），Windows NT 6.1（内部版本 7601：Service Pack 1）（管理程序）

服务器版本（链接）：

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 2011 年 6 月 17 日 00:54:03 版权所有 (c) Microsoft Corporation Enterprise …

我正在使用 ASP Web API、实体框架和 SQL Server/Azure 数据库构建多租户应用程序（单一数据库、单一架构）。此应用程序将被 1000-5000 名客户使用。所有的表都会有TenantId(Guid / UNIQUEIDENTIFIER) 字段。现在，我使用单字段主键，即 Id (Guid)。但是通过仅使用 Id 字段，我必须检查用户提供的数据是否来自/用于正确的租户。例如，我有一个SalesOrder包含CustomerId字段的表。每次用户发布/更新销售订单时，我都必须检查它CustomerId是否来自同一个租户。情况变得更糟，因为每个租户可能有多个网点。然后我必须检查TenantId和OutletId。这真的是一个维护噩梦，对性能不利。

我想添加TenantId主键沿Id。也可能添加OutletId。所以SalesOrder表中的主键将是：Id、TenantId、 和OutletId。这种方法的缺点是什么？使用复合键会严重影响性能吗？复合键顺序重要吗？我的问题有更好的解决方案吗？