小编Ore*_*reo的帖子

我正在使用一个报告数据库，它实际上是一个只读数据库。它是创建的数据，并在此数据库上生成和查看动态报告。

我正在考虑将此数据库设为只读。

关于只读数据库，我想问的一些问题是

1. 只有数据是只读的吗？我们还能在这个数据库上创建索引或视图吗？
2. 使用只读数据库有哪些性能优势？例如使用共享锁的 SELECT 查询等...
3. 使用只读数据库有什么缺点吗？
4. 在使用只读数据库时，是否有任何最佳实践可以遵循？

我们有一个运行 PowerShell 的 SQL 代理作业，它创建了一个很长的输出（它有 robocopy 输出等）。

在 SQL 代理作业历史记录中，我们只能看到此输出的前 1,000 个字符左右。

1. 是否还有其他地方可以查看整个输出？
2. 是否应该使用另一种方法来查看完整输出？

我有两个实例ServerA和ServerB，并且我在ServerA 中为ServerB创建了一个链接服务器作为Linksrv_B。

我可以使用四部分命名约定在ServerA上执行查询：

SELECT * FROM Linksrv_B.master.sys.databases

或OPENQUERY()：

SELECT * FROM OPENQUERY(Linksrv_B, 'SELECT * FROM master.sys.databases')  

我知道链接服务器使用分布式事务作为行集跨异构数据库工作。

1. OLEDB 提供程序在哪里启动/连接？服务器A还是服务器B？
2. 查询是在 ServerA 还是 ServerB 上执行的？优化器是否在哪个服务器上发挥作用？
3. 结果集在哪里缓存？
4. 谁能给我们一个详细的解释链接服务器是如何工作的。

从多个来源频繁插入表时，我从表上的间隙锁中获得死锁。这是我的流程的概述。

START TRANSACTION
  UPDATE vehicle_image
  SET active = 0
  WHERE vehicleID = SOMEID AND active = 1

  Loop:
    INSERT INTO vehicle_image (vehicleID, vehicleImageFilePath, vehicleImageSplashFilePath
      ,vehicleImageThumbnailFilePath, vehicleImageMiniFilePath, mainVehicleImage, active)
    VALUES (%s, %s, %s, %s, %s, %s, 1);
END TRANSACTION

的输出SHOW Create table vehicle_image;是：

CREATE TABLE `vehicle_image` (
  `vehicleImageID` int(11) NOT NULL AUTO_INCREMENT,
  `vehicleID` int(11) DEFAULT NULL,
  `vehicleImageFilePath` varchar(200) DEFAULT NULL,
  `vehicleImageSplashFilePath` varchar(200) DEFAULT NULL,
  `vehicleImageThumbnailFilePath` varchar(200) DEFAULT NULL,
  `vehicleImageMiniFilePath` varchar(200) DEFAULT NULL,
  `mainVehicleImage` bit(1) DEFAULT NULL,
  `active` bit(1) DEFAULT …

我最近向 SQL Server 添加了更多 CPU 内核，并且按照最佳实践的建议，我将 tempDB 文件分成相同数量的内核 (8)。

除了最佳实践之外，我还扩大了新 tempdb 文件的大小、限制了自动增长并缩小了原始文件以匹配新文件的大小。

问题是，由于我从单核变为 8 核，所有 tempdb 数据都保留在第一个文件中，这不允许我缩小。现在我有一个比其他文件大的 tempdb 文件，我想更改它。

我怀疑要解决这个问题需要停机。

1. 有没有办法在不停机的情况下做到这一点？

2. 这个问题值得解决吗？我知道最佳实践怎么说，但是这个实例真的会导致除了丑陋之外的任何实际问题吗？

我有点困惑。TRUNCATEONLYSQL 2012 中的参数是否已更改，或者 SQL 2008 R2 中的文档是否有误？

2008 R2

将文件末尾的所有可用空间释放给操作系统，但不会在文件内执行任何页面移动。数据文件仅收缩到最后分配的范围。如果使用 TRUNCATEONLY 指定，则忽略 target_percent。

TRUNCATEONLY 仅适用于数据文件。日志文件不受影响。

最后一条语句让我觉得这对日志文件根本没有影响？

2012年

将文件末尾的所有可用空间释放给操作系统，但不会在文件内执行任何页面移动。数据文件仅收缩到最后分配的范围。如果使用 TRUNCATEONLY 指定，则忽略 target_percent。

TRUNCATEONLY 影响日志文件。要仅截断数据文件，请使用 DBCC SHRINKFILE。

最后一条语句现在告诉我它只影响日志文件？

那么是功能改变了，还是文档中有错误，或者我的解释有误？

使用Ola Hallengren 的 SQL Server 维护解决方案时，作业输出日志将转到 SQL 服务器上的本地目录。我正在考虑将这些日志放在文件服务器上，以允许更多人访问，以便他们可以查看作业输出。

我的问题是：

1. 如何更改此位置？
2. 改变位置有什么坏处吗？

谢谢！

我们有一个 SQL Server 解决方案，它有一个表dsStaging.Audit，用于存储由第三方事务数据库创建的审计记录。我们使用这些审计将来自第三方系统的 CRUD 操作同步到我们的 SQL 数据库中。

CREATE TABLE [dsStaging].[Audit](
    [SyncExecutionId] [bigint] NOT NULL,
    [AuditDataGuid] [nvarchar](56) NOT NULL,
    [AuditDate] [datetime] NOT NULL,
    [AuditDateTimeZone] [datetimeoffset](3) NULL,
    [AuditEventGroup] [nvarchar](56) NOT NULL,
    [TransactionId] [bigint] NOT NULL,
    [TransactionSequence] [int] NOT NULL,
    .
    ...
    .
 CONSTRAINT [PK_Audit] PRIMARY KEY CLUSTERED 
(
    [SyncExecutionId] ASC,
    [TransactionId] ASC,
    [TransactionSequence] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
    IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

处理审计后，我想将审计记录移动到一个单独的表中Processed.Audit，准备在 x 天后删除。

CREATE TABLE …

我面临 SQL Server 生成非最佳执行计划的问题：嵌套循环连接并寻找维度表并对其执行 2M 读取。

排序操作估计是 100 行而不是 450 K 行，可能会影响计划选择：

NestedLoop：https ://www.brentozar.com/pastetheplan/ ? id = B110MZ2Pm或 NestedLoop 计划

这是在测试数据库中。我们有一个具有相同架构和几乎相同数据的附加数据库。

运行完全相同的查询（均来自 SSMS）使用哈希联接和维度表扫描（32K 读取）生成不同的计划：

HashJoin：https ://www.brentozar.com/pastetheplan/ ? id = r1Jm7b2D7或 哈希计划

我需要帮助来理解和解决问题。

我可以通过提示 Hash Joint 来解决这个问题，但是同一实例上的 2 个相似的 DB 生成不同的计划没有任何意义。

更新 #1：我发现估计的成本是不同的所以当 SQL Server 并行执行时，它会选择一个散列连接。

用单线程会嵌套循环。

更新 #2：在从同一个表中进行 SELECT 时发生了同样的问题。取决于列数（估计成本）。当我减少列数时，执行计划陷入嵌套循环并寻找维度表。

SSMS 脚本外键约束为两个语句：

ALTER TABLE {table}
WITH CHECK
ADD CONSTRAINT {constraintname} {constraint spec}
GO

ALTER TABLE {table}
CHECK CONSTRAINT {constraintname}
GO

第二个陈述的目的是什么？