标签: sql-server-2017

我 在 Ubuntu (Linux) 上安装了mssql-server和mssql-tools。当我尝试使用以下命令行使用bcp命令导出数据时：

bcp DBname.dbo.Täble_Name out Täble_Name -c -k  -S127.0.0.1 -Usa -PpassWord -r ~

我收到此错误：

SQLState = 37000，NativeError = 102
错误 = [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]'?' 附近的语法不正确。

该?是ä。

如果我Täble_Name用方括号括起来：

 bcp DBname.dbo.[Täble_Name] out Täble_Name -c -k  -S127.0.0.1 -Usa -PpassWord -r ~

我在对象名称上收到此错误：

SQLState = S0002，NativeError = 208
错误 = [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]无效的对象名称“DBname.dbo.Täble_Name”。

我进一步添加了单引号''以及-q选项（启用带引号的标识符）：

bcp 'DBname.dbo.[Täble_Name]' out …

我正在寻找有关如何使用手动播种设置分布式可用性组的分步演练。我可以让自动播种工作，但是当我尝试手动播种时，我无法将辅助数据库放入转发器上的 AG。

如果我在尝试将数据库添加到常规 AG 之前将分布式 AG 添加到辅助服务器，则会收到以下消息：

Msg 41190, Level 16, State 7, Line 22
Availability group 'MYDB' failed to process add-database command.  The local availability replica is not in a state that could process the command.  Verify that the availability group is online and that the local availability replica is the primary replica, then retry the command. 

如果我尝试先添加数据库而不加入辅助数据库上的分布式 AG，我会收到以下消息，因为它认为它应该是主数据库：

Msg 927, Level 14, State 2, Line 22
Database 'MYDB' cannot be opened. It is in the middle of a …

根据 MS-DOCS about System information schema views，架构列定义有一个警告说明：

**重要** 不要使用 INFORMATION_SCHEMA 视图来确定对象的架构。查找对象架构的唯一可靠方法是查询 sys.objects 目录视图。

为什么不能使用 INFORMATION_SCHEMA 视图来确定对象的架构？

这个信息有误吗？

长话短说，我们正在使用非常大的人员表中的值更新小型人员表。在最近的测试中，此更新需要大约 5 分钟才能运行。

我们偶然发现了看似最愚蠢的优化方法，但它似乎完美无缺！相同的查询现在可以在不到 2 分钟的时间内运行并完美地产生相同的结果。

这是查询。最后一行被添加为“优化”。为什么查询时间急剧减少？我们错过了什么吗？这会导致将来出现问题吗？

UPDATE smallTbl
SET smallTbl.importantValue = largeTbl.importantValue
FROM smallTableOfPeople smallTbl
JOIN largeTableOfPeople largeTbl
    ON largeTbl.birth_date = smallTbl.birthDate
    AND DIFFERENCE(TRIM(smallTbl.last_name),TRIM(largeTbl.last_name)) = 4
    AND DIFFERENCE(TRIM(smallTbl.first_name),TRIM(largeTbl.first_name)) = 4
WHERE smallTbl.importantValue IS NULL
-- The following line is "the optimization"
AND LEFT(TRIM(largeTbl.last_name), 1) IN ('a','à','á','b','c','d','e','è','é','f','g','h','i','j','k','l','m','n','o','ô','ö','p','q','r','s','t','u','ü','v','w','x','y','z','æ','ä','ø','å')

技术说明：我们知道要测试的字母列表可能需要更多的字母。我们也意识到使用“DIFFERENCE”时明显的误差幅度。

查询计划（常规）： https : //www.brentozar.com/pastetheplan/?
id = rypV84y7V 查询计划（带“优化”）：https : //www.brentozar.com/pastetheplan/?id=r1aC2my7E

我在 Windows Server 2012 R2 上运行 SQL Server 2017，并将内存从 256 GB 增加到 512 GB。我注意到虚拟内存的以下配置：

• C: [操作系统] = 2 GB
• G：[数据] = 无
• H：[日志] = 无
• T：[温度] = 无

有很多关于将大小设置为已安装内存大小的 1.5 或 2 倍的建议。我读得对还是我误读了这些文章并且它们适用于其他东西？

也有文章建议不要担心虚拟内存，因为SQL应该只使用RAM而不是虚拟内存，而操作系统只需要2GB的虚拟内存？

我们的主数据库的大小已经减少了大约 8 GB。这反映在备份以及我们查看可用空间和可用空间时。

一切似乎都在工作，我们找不到任何数据丢失的迹象，但我们以前从未见过这种情况。我们有点担心可能会发生一些不愉快的事情。

谁能告诉我们 8 GB 的数据是如何消失的？如果这是一件正常的事情，我们想了解它是如何发生的，因为能够将数据库备份的大小减半实际上有点有用。

我们在 Windows Server 2019 上运行 SQL Server Enterprise 版本 14.0.3391.2

我们的主数据库每天午夜后备份。备份目标是本地磁盘。每次备份运行时，都会为每个数据库创建一个新文件。我们的恢复模式很简单。备份不会被压缩。至少在过去几年中，每个备份大约为 15 GB。自 6 月 11 日以来，文件大小已缩减至略高于 7 GB。

做一些研究，DBA StackExchange 上的一个线程与不小心在单个文件中创建多个备份的人有关。我RESTORE HEADERONLY FROM DISK对 6 月 10 日（15 GB）和 6 月 11 日（7 GB）的备份进行了测试。两者似乎都包含一个备份。我也没有看到任何其他值得注意的差异。

恢复数据库后，我观察到当前和恢复的数据库的总大小约为 30 GB。当前数据库上的可用空间约为 19 GB，而在恢复的数据库上约为 11 GB。8 GB 的差异，就像备份一样。我们的备份未压缩。

我们没有注意到我们的应用程序中缺少任何我们非常依赖的数据。我已经使用 SSDT 来比较当前数据库和恢复数据库中的架构和数据。

使用此数据库的应用程序正在不断开发中，因此在当前数据库中添加了一些列和表以支持新功能，但没有删除。

同样，在当前数据库中也有一些行被编辑或删除，但关联表在恢复的数据库中所占的比例远低于 100 MB，因此即使它们被完全删除，也不会导致大约 8 GB 的数据消失。

我们有一个人来开发应用程序。数据库管理由那个人和我共享。我们都不相信我们做了任何会导致这种变化的事情。

我们使用数据库的方式没有任何重大变化，如果有的话，备份应该变得更大。

我们是一家小公司，不太可能有人进行过数据清理。这也应该在 SSDT 的数据比较中显示出来。

我在日志文件中没有发现任何表明未经授权访问或备份失败的信息。

我目前正在从 6 月 11 日 (7 GB) 恢复备份，看看这是否能告诉我任何信息，尽管我并不期望从中获得太多见解。

我们不会自动删除备份，而是手动删除，这时我们发现了大小差异。

我不相信任何索引已被删除-有人对最佳检查方法有建议吗？碎片整理似乎是一个完全可能的原因 …

sp_whoisactive第一次在服务器上运行时，我遇到了一些意想不到的事情：

两场比赛已经持续了13天，但两场比赛似乎都在互相阻碍。看看sys.dm_tran_locks：

阻止进程阈值设置的配置值为 10 秒。其他死锁正在通过死锁监视器在服务器上成功解决。

来自参数的信息@get_locks：

<Database name="DB1">
  <Locks>
    <Lock request_mode="S" request_status="GRANT" request_count="1" />
  </Locks>
  <Objects>
    <Object name="TBL1" schema_name="dbo">
      <Locks>
        <Lock resource_type="OBJECT" request_mode="IX" request_status="GRANT" request_count="1" />
        <Lock resource_type="PAGE" page_type="*" index_name="PK__TBL1__3214EC27326C5B6A" request_mode="U" request_status="GRANT" request_count="1" />
        <Lock resource_type="PAGE" page_type="*" index_name="PK__TBL1__3214EC27326C5B6A" request_mode="U" request_status="WAIT" request_count="1" />
      </Locks>
    </Object>
  </Objects>
</Database>


<Database name="DB1">
    <Locks>
        <Lock request_mode="S" request_status="GRANT" request_count="1" />
    </Locks>
    <Objects>
        <Object name="TBL2" schema_name="dbo">
            <Locks>
                <Lock resource_type="OBJECT" request_mode="Sch-S" request_status="GRANT" request_count="2" />
            </Locks>
        </Object>
        <Object name="TBL1" schema_name="dbo">
            <Locks>
                <Lock resource_type="OBJECT" request_mode="IX" …

考虑以下查询，该查询对少量标量聚合进行了反透视：

SELECT A, B
FROM (
    SELECT 
      MAX(CASE WHEN ID = 1 THEN 1 ELSE 0 END) VAL1
    , MAX(CASE WHEN ID = 2 THEN 1 ELSE 0 END) VAL2
    , MAX(CASE WHEN ID = 3 THEN 1 ELSE 0 END) VAL3
    , MAX(CASE WHEN ID = 4 THEN 1 ELSE 0 END) VAL4
    , MAX(CASE WHEN ID = 5 THEN 1 ELSE 0 END) VAL5
    , MAX(CASE WHEN ID = 6 THEN 1 ELSE 0 END) VAL6
    , MAX(CASE …

在 PostgreSQL 中，我可以创建一个包含一些测试数据的表，然后在事务中将其迁移到不同类型的新列，从而导致一个表重写COMMIT，

CREATE TABLE foo ( a int );
INSERT INTO foo VALUES (1),(2),(3);

其次是，

BEGIN;
  ALTER TABLE foo ADD COLUMN b varchar;
  UPDATE foo SET b = CAST(a AS varchar);
  ALTER TABLE foo DROP COLUMN a;
COMMIT;

但是，Microsoft 的 SQL Server 中的相同内容似乎会产生错误。比较这个工作db fiddle，其中ADD（列）命令在事务之外，

-- txn1
BEGIN TRANSACTION;
  ALTER TABLE foo ADD b varchar;
COMMIT;

-- txn2
BEGIN TRANSACTION;
  UPDATE foo SET b = CAST( a AS varchar );
  ALTER TABLE …

所以我们有一个带有错字的子查询的查询。它缺少 FROM 子句。但是当你运行它时，它不会出错！为什么！？

SELECT

    1
   ,r.id
   ,'0D4133BE-C1B5-4141-AFAD-B171A2CCCE56'
   ,GETDATE()
   ,1
   ,'Y'
   ,'N'
   ,oldItem.can_view
   ,oldItem.can_update

FROM Role r

JOIN RoleObject oldReport
    ON r.customer_id = oldReport.customer_id

JOIN RoleItem oldItem
    ON oldReport.id = oldItem.role_object_id
        AND r.id = oldItem.role_id

WHERE r.id NOT IN (SELECT
        role_id
    WHERE role_object_id = '0D4133BE-C1B5-4141-AFAD-B171A2CCCE56')

AND oldReport.id = '169BA22F-1614-4EBA-AF45-18E333C54C6C'