标签: sql-server

我最近作为 DBA 实习生开始使用 SQL Server 2008。我需要计算数据库的大小，还要估计它最近几个月的增长以及未来 12 个月的预测增长。

我可以使用 sp_spaceused 语句来计算实际大小，但如何计算其他所有内容？

标量 UDF 强制执行整体串行计划，这是有据可查的。

并行运行函数

给定大量行进入管道中必须计算 UDF 的点，为什么引擎不能将它们分配给处理器？如果 UDF 中没有状态，那么顺序应该无关紧要。

有人声称 UDF 是一个必须使用光标的黑匣子。我可以看到，对于在迭代之间维护某些状态但似乎应该可以并行化的情况，用户游标无法在 SP 中并行化。

解释为什么引擎强制整个计划是串行的，而不仅仅是 UDF 计算阶段的额外要点。

对并行 UDF 的支持是一个合理的要求吗？

好的，设置场景。我有三个表，（ Table1，Table2和DataTable），我想插入Table1和Table2使用DataTable作为源。因此，对于每一行，DataTable我都希望在Table1and 中有一排Table2，并且Table2需要id从Table1...插入（PK）

如果我要这样做...

INSERT INTO Table1 SELECT A, B, C FROM MyTable
INSERT INTO Table2 SELECT IDENTITY_INSERT(), D, E, F FROM MyTable

我将ID最后插入的记录的Table1.

是CURSOR或WHILE循环来做到这一点的唯一途径？

通常，在将数据库从生产服务器还原到非生产服务器时，我将使用 WITH REPLACE 选项，因为当我忘记收到有关未备份尾日志的错误时。

根据 MSDN我确实应该在恢复之前备份我的尾部日志：

如果数据库处于联机状态并且您计划对数据库执行还原操作，请先备份日志的尾部。为避免联机数据库出现错误，您必须使用 BACKUP Transact-SQL 语句的 ... WITH NORECOVERY 选项。

我这样做的方式有哪些危险或缺点？为什么首先备份尾部日志对我有利？

我正在使用 SQL Server 2008R2，但我认为这个查询将与大多数较新版本的 SQL Server 相关，因此最初没有将其标记为这样。

我有一个table1在db1和table2在db2上的SQL Server 2008 R2。

如果我做一个选择查询加入两个表，得到结果真的很慢。

一个简单的查询，如

SELECT * 
FROM db1.dbo.table1 t1 
LEFT JOIN db2.dbo.table2 t2 ON t1.k1 = t2.k2

有时真的很慢。

我不确定这是否对 SQL Server 很常见，并且“必须像规则一样”“不连接来自不同数据库的两个表”。

在那种情况下......我补充说这个问题，我有一个存储在一个字段上的数据库二进制数据，我喜欢与主数据库分开而不增加主表的大小......最好为此对数据库进行分区?

我用两个简单的表进行了测试，但加入这两个表仍然很慢。

在此先感谢您的帮助。

..几年后更新... 24-09-18

确保您加入的字段具有相同的类型、大小和排序规则。

示例：某些属性是 varchar(255) 和另一个 varchar(20) ......这可能是一个问题，因为引擎必须将一种类型转换为另一种类型（发生隐式转换），而有时它运行得更快......如果重新索引或数据库发生一些变化，你可以看到在某个时刻查询开始花费更多的时间来完成......

如果您无法更改字段类型以匹配其中一个 db/tables，请尝试执行显式转换以查看是否可以提高查询速度。用 cast(fieldname as type(size)) = fieldName2)

我为 .ndf 创建了太多辅助数据文件 (.ndf) tempdb。要删除多余的文件，我需要清空文件（内容将移动到其他文件）：

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

然后删除文件：

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

但是EMPTYFILE命令返回错误：

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

不用担心，我只需要找到使用此页面的对象即可：

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

该命令返回了很多信息，其中的object_id。但：

Metadata: ObjectId = 0 

我不知道该怎么办。什么猫阻止了这个页面被移动？如何定位该对象、进程、会话或其他任何内容？任何帮助将不胜感激，但请注意保持原样或删除其他文件不是解决此问题的有效方法;)。

编辑：

我正在删除这些文件，因为我们曾经遵循“最佳实践”，即为每个处理器内核创建一个文件（相同的初始大小，相同的增长率）。但据我所知，在遇到争用问题之前，没有必要在同一设备上创建额外的 tempdb 文件。在我们的例子中，这是有道理的，因为我们打开了MPIO，并且存储设备可以处理 4 个路径。但是有一个错误，我们最终得到了 …

当我们对一个表的聚集索引进行重建时，该表中有大约 15GB 的数据并且数据大小缩小到 5GB，这怎么可能？删除了什么样的“数据”？

数据大小我指的是 DBCC sp_spaceused 的“数据”列

在聚集索引上重建之前：

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    39169656 KB 15857960 KB 22916496 KB 395200 KB

Run Code Online (Sandbox Code Playgroud)

---

在聚集索引上重建后：

name                  rows        reserved    data        index_size  unused
LEDGERJOURNALTRANS    43583730    29076736 KB 5867048 KB  22880144 KB 329544 KB

Run Code Online (Sandbox Code Playgroud)

用于重建的 TSQL：

USE [DAX5TEST]
GO
ALTER INDEX [I_212RECID] ON [dbo].[LEDGERJOURNALTRANS] REBUILD PARTITION = ALL WITH ( PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = OFF, DATA_COMPRESSION = PAGE, FILLFACTOR …

我需要允许用户在没有任何能力启动其他代理的情况下启动特定的代理作业。为此，我创建了以下过程（简化）：

ALTER PROCEDURE [dbo].[RunJob]
    @job_name nvarchar(200)
WITH EXECUTE AS 'sysadminaccount'
AS
BEGIN
    --SET NOCOUNT ON;
    BEGIN TRY
        EXEC msdb.dbo.sp_start_job @job_name = @job_name 

        -- Wait for job to finish
        DECLARE @job_history_id AS INT = NULL
        DECLARE @job_result AS INT = NULL

        WHILE 1=1
        BEGIN
            SELECT TOP 1 @job_history_id = activity.job_history_id
            FROM msdb.dbo.sysjobs jobs
            INNER JOIN msdb.dbo.sysjobactivity activity ON activity.job_id = jobs.job_id
            WHERE jobs.name = @job_name
            ORDER BY activity.start_execution_date DESC

            IF @job_history_id IS NULL
            BEGIN
                WAITFOR DELAY '00:00:01'
                CONTINUE
            END
            ELSE
                BREAK …

我有一个运行得很慢的查询，所以我开始研究执行计划。TRY_CAST是一种确定数据是否可以转换为类型的安全方法。并且计划中有关于 的警告TRY_CAST。

 Type conversion in expression try_cast may affect "CardinalityEstimate" in query plan choice

请注意，我不是 DBA 而是编码员。当我谈到数据库的东西时，把我当作一个新手。

提高查询速度的最佳方法应该是什么（基于此问题标题中的警告）？除此之外还有什么TRY_CAST可能有助于加快查询速度，例如，CAST它本身很容易出现异常，而我所知道的安全转换的唯一方法是TRY_CAST？

我有一个带有聚集索引和 2 个非聚集索引的表。现在，在我看来，我正在从我的表中选择所有内容

create view dbo.MyView
as 
Select * from MyTable

现在，当我在查询中使用这个视图时，我可以假设这个视图将利用在表上创建的索引。（即与Select * from MyTable 的工作方式相同）？或者我应该使用索引视图

补充问题

如果视图可以利用表索引，那么使用SELECT * FROM MyView Where SomeColumn = @someValue可能会严重影响性能（如果视图有大量数据，那么它在没有索引时会表现得像堆）。如何克服这个问题？除了使用 NOEXPAND（因为我使用的是企业版）