标签: sql-server

我有一个奇怪的要求，要安排报告并将其打印到打印机。

报告本身非常简单，可以放在一个页面上。我可以将它打印到 txt 中，这样就可以了（尽管我愿意接受关于更好产品的建议）。

这是代码。有用。但我不喜欢。具体来说，我想取消嵌套的@bcp 和@SQL。

问题：有没有更优雅的方法来做到这一点？

declare @filepath varchar(255),
@filename varchar(255),
@filetype varchar(255),
@sql nvarchar(max),
@coverpage_text nvarchar(max)

set @filepath = 'C:\users\jmay\documents\'
SET @filename = 'TestFile'
set @filetype = '.txt'

--output to txt
set @sql = N'declare @bcp varchar(4000)
set @bcp = ''bcp " select * from test_data " queryout ' 
+ @filepath +  @filename + @filetype + ' -t " - " -c -T -d DBA''
print @bcp

EXECUTE master.dbo.xp_cmdshell @BCP'

print @sql
 exec sp_executesql @sql …

如果您没有听说过，最近发现了一组相关漏洞，这些漏洞影响了过去十年中销售的几乎所有处理器。您可以在 InfoSec.SE 上找到有关崩溃/幽灵漏洞的更多技术细节。

作为 SQL Server DBA，我需要了解什么？

如果我们不与其他公司共享我们的 SQL Server（或我们的虚拟机群），这是否仍然存在风险？

这只是一个操作系统补丁吗？或者是否有可用于解决此漏洞的 SQL Server 补丁/修补程序？将修补哪些 SQL Server 版本？

一些文章预测了 5-30% 的性能影响，尤其是在高度虚拟化的环境中。有什么方法可以预测对我的 SQL Server 的性能影响可能是什么？

在我目前的环境中，我正在与 NOLOCK 作斗争。我听到的一个论点是锁定的开销会减慢查询速度。所以，我设计了一个测试来看看这个开销可能有多少。

我发现 NOLOCK 实际上减慢了我的扫描速度。

起初我很高兴，但现在我很困惑。我的测试以某种方式无效吗？NOLOCK 实际上不应该允许稍微快一点的扫描吗？这里发生了什么事？

这是我的脚本：

USE TestDB
GO

--Create a five-million row table
DROP TABLE IF EXISTS dbo.JustAnotherTable
GO

CREATE TABLE dbo.JustAnotherTable (
ID INT IDENTITY PRIMARY KEY,
notID CHAR(5) NOT NULL )

INSERT dbo.JustAnotherTable
SELECT TOP 5000000 'datas'
FROM sys.all_objects a1
CROSS JOIN sys.all_objects a2
CROSS JOIN sys.all_objects a3

/********************************************/
-----Testing. Run each multiple times--------
/********************************************/
--How fast is a plain select? (I get about 587ms)
DECLARE @trash CHAR(5), @dt DATETIME = SYSDATETIME()

SELECT @trash …

我正在努力理解为什么行估计如此错误，这是我的情况：

简单联接 - 使用 SQL Server 2016 sp2（sp1 上的相同问题），dbcompatibity=130。

select Amount_TransactionCurrency_id, CurrencyShareds.id 
from CurrencyShareds 
    INNER JOIN annexes ON Amount_TransactionCurrency_id = CurrencyShareds.Id 
option (QUERYTRACEON 3604, QUERYTRACEON 2363);

SQL 估计 1 行，而它是 107131 并选择执行嵌套循环（链接到计划）。在 CurrencyShareds 上更新统计信息后，估计就可以了，并选择合并连接（链接到新计划）。只要将一条记录添加到 CurrencyShareds，统计信息就会变得“陈旧”并且 sql 返回错误估计。

我不会太担心这个简单的查询，但这只是更大查询的一部分，这是多米诺骨牌的开始......

为什么在 100 条记录表中添加一行会导致这样的损坏？在查看基数估计跟踪的输出时，我看到了这个警告，***WARNING: badly-formed histogram ***但我找不到关于这个主题的更多信息。

以下是基数估计的完整输出：

Begin selectivity computation
Input tree:

LogOp_Join

CStCollBaseTable(ID=1, CARD=107131 TBL: annexes)

CStCollBaseTable(ID=2, CARD=100 TBL: CurrencyShareds)

ScaOp_Comp x_cmpEq

ScaOp_Identifier QCOL: [test.MasterData].[dbo].[CurrencyShareds].Id

ScaOp_Identifier QCOL: [test.MasterData].[dbo].[Annexes].Amount_TransactionCurrency_id

Plan for computation:

CSelCalcExpressionComparedToExpression( QCOL: [test.MasterData].[dbo].[Annexes].Amount_TransactionCurrency_id x_cmpEq …

我正在测试不同场景中的最少日志记录插入，并且从我读到的 INSERT INTO SELECT 到带有非聚集索引的堆中，使用 TABLOCK 和 SQL Server 2016+ 应该最少记录，但是在我的情况下，这样做时我得到完整记录。我的数据库处于简单恢复模型中，我成功地在没有索引和 TABLOCK 的堆上获得了最少记录的插入。

我正在使用 Stack Overflow 数据库的旧备份进行测试，并使用以下架构创建了 Posts 表的副本...

CREATE TABLE [dbo].[PostsDestination](
    [Id] [int] NOT NULL,
    [AcceptedAnswerId] [int] NULL,
    [AnswerCount] [int] NULL,
    [Body] [nvarchar](max) NOT NULL,
    [ClosedDate] [datetime] NULL,
    [CommentCount] [int] NULL,
    [CommunityOwnedDate] [datetime] NULL,
    [CreationDate] [datetime] NOT NULL,
    [FavoriteCount] [int] NULL,
    [LastActivityDate] [datetime] NOT NULL,
    [LastEditDate] [datetime] NULL,
    [LastEditorDisplayName] [nvarchar](40) NULL,
    [LastEditorUserId] [int] NULL,
    [OwnerUserId] [int] NULL,
    [ParentId] [int] NULL,
    [PostTypeId] [int] NOT NULL,
    [Score] [int] NOT NULL,
    [Tags] …

我的供应商要求数据仓库数据库区分大小写，但我需要对其进行不区分大小写的查询。

在区分大小写的数据库中，您如何将其编写为不区分大小写？

    Where Name like '%hospitalist%'

我试图从存储和性能角度了解决定 varchar 列应该有多大的最佳方法。

性能
从我的研究来看，似乎varchar(max) 只应在您确实需要时使用；也就是说，如果该列必须容纳超过 8000 个字符，一个原因是缺乏索引（尽管我对一般的 varchar 字段的索引有点怀疑。不过，我对 DB 原则还很陌生，所以也许这是没有根据的) 和压缩（更多的是存储问题）。事实上，一般来说，人们似乎只推荐使用你需要的东西，当做 varchar(n)....oversizing 是不好的，因为查询必须考虑到最大可能的大小。但也有人表示，引擎将使用指示大小的一半作为数据平均实际大小的估计值。这意味着人们应该根据数据确定平均大小是多少，将其翻倍，并将其用作 n。对于具有非常低但非零可变性的数据，这意味着比最大尺寸大 2 倍，这看起来很多，但也许不是？见解将不胜感激。

存储
在阅读了行内与行外存储的工作原理后，并记住实际存储仅限于实际数据，在我看来，n 的选择实际上对存储几乎没有影响（除了确保它足够大以容纳所有东西）。即使使用 varchar(max) 也不会对存储产生任何影响。相反，如果可能，目标可能是将每个数据行的实际大小限制为 ~8000 字节。这是对事物的准确阅读吗？

上下文
我们的一些客户数据会稍微波动，因此我们通常将这些列的列设置得比它们需要的宽度稍宽一些，比如大 15-20%。我想知道是否还有其他特殊考虑；例如，和我一起工作的人告诉我使用 2^n - 1 个尺寸（不过我没有发现任何证据......）

我说的是初始表的创建。客户会告诉我们他们将开始向我们发送一个新表，并发送示例数据（或只是第一个生产数据集），我们会查看这些数据并在我们的一端制作一个表来保存数据。我们希望在我们的一端制作表格以处理未来的导入以及样本中的内容。但是，某些行肯定会变长，所以我们填充它们。

问题是多少，是否有技术指南？

我如何在生产框中检查我的 SQL 服务器的内存使用情况。我正在使用 SQL Server 2016。当我检查任务管理器时，它显示在 90% 以上。我不认为这是 sql server 的真实内存使用情况。

我有一个 SQL 性能工具 grafana，它显示的 CPU 使用率比我在任务管理器中看到的少得多。我检查了资源监视器，可以看到平均 CPU 值。我对 SQL 服务器内存使用情况感到困惑。我正在尝试确定内存压力是否是我的某些问题的一个问题。

有人可以直接给出一个好的/正确的解释。

我有一个 SQL Server 数据库，其中的查询速度很慢，而且有很多锁定和阻塞。

当我查看缺失的索引 DMV 和查询计划时，没有任何建议。

这是为什么？

我有一个存储过程：

• 检查表是否存在，如果存在，则删除它。
• 再次创建该表
• 然后用大约 30 个查询填充该表。

当我（数据库所有者）运行这个过程时，一切都按预期工作。当我的同事通过 Active Directory 中的角色对该数据库具有 DROP/CREATE 权限时，会出现一些问题。令我困惑的是：

表的创建没有dbo在名称前显式指定架构。这导致domain\cowork_id.table_name_here创建一个名为table 的表。除了在他的个人模式中创建的表之外，他现在还在数据库中拥有该模式（在运行 proc 之前它不存在）。

发生了什么？为什么 SQL Server 在用户架构中创建表而不是在dbo未指定时创建表？