标签: database-internals

SSD = 固态硬盘

我们有一个关于服务器 CRM01（营销 CRM 服务器 - 运行大型查询）上的 tempDB 性能的具体问题：

在 CRM01 上，tempDB 数据和日志文件驻留在固态驱动器上。SSD 总大小为 400Gb。Tempdb 数据文件占用 300 Gb，日志占用约 100 Gb，可能需要增加但没有剩余空间。

这个问题是理论上的。我们确实理解： - 如果 tempdb 日志文件增长太多，我们应该拆分我们的进程，以便数据应该以更小的块处理，或者我们应该考虑使用可能的临时物理表而不是 tempdb。

• 数据和日志 tempdb 文件都应保留在 SSD 上以优化性能

但是，如果由于空间限制我们真的不得不决定将一些 tempdb 文件移出 SSD，您会选择将哪些文件移至标准的快速驱动器：数据文件还是日志文件？

什么不是 tempDB，它是一个普通的 DB。当然，我可以对表进行分区，并创建不同的文件组，但我仍然会将数据或日志保存在最快的磁盘中吗？

假设利用率为 50% 读取和 50% 更新和插入。

@Moderator，我同意问题的第二部分不客观，但它提供了见解和想法。

给定一个表格...

create table dbo.FilterIDXTest ( 
    id int not null identity primary key clustered,
    _bigint bigint,
    _varchar10 varchar(10),
    _varchar20 varchar(20),
    _guid uniqueidentifier
);

go

create unique index uq_FilterIDXTest
    on dbo.FilterIDXTest ( _varchar10, _varchar20 ) 
    include ( _guid )
    where _bigint is not null 
        and id > 5;

go

...在什么（如果有）目录视图（或其他格式良好的参考对象）中可以WHERE定位和严格识别子句中的列名称？

sys.indexes可以查看提醒我们的filter_definition是([_bigint] IS NOT NULL AND [id]>(5))。

sys.index_columns可以查看ON和INCLUDE列，但仅列出原始CREATE INDEX命令中的 5 列中的 3 列。filter_predicate此处未找到这些列。

我必须假设filter_predicate在某个阶段对依赖项进行了严格检查，因为sp_rename …

我一直在 Pluralsights 上观看Paul Randal撰写的SQL Server：高级损坏恢复技术。在第 4 单元中，他讨论了一个事实，即如果您丢失了日志文件，那么了解数据库是否完全关闭是很重要的。这将决定 SQL Server 是否会运行崩溃恢复。

他继续提到，这个标志可以在数据库引导页面中找到（1:9 是我基于课程材料的假设，并通过microsoft 上的这个链接备份）。但是，我在页面内没有看到任何明显的标志 -

DBCC TRACEON (3604);
DBCC PAGE ('stack',1, 9, 2) WITH TABLERESULTS;
DBCC TRACEOFF (3604);

在网上查找时，我找不到有关引导页面 (1:9) 的信息。我能够找到sys.databases一列is_cleanly_shutdown代表：

1 = 数据库完全关闭；启动时无需恢复

0 = 数据库没有完全关闭；启动时需要恢复

但是，我想跟随课程，有人可以告诉我在引导页面中寻找什么吗？另外，如何让数据库显示它已完全关闭或执行此操作的正确步骤？

我正在运行 SQL Server 2012。

几天来，我一直在工作中的网络上进行挖掘，试图弄明白 DBMS（SQL Server 2008 R2 和其他）如何如此快速地将一列添加到大表的末尾。

在高层次上，您可以认为：我可以在末尾放置一个指向新列的指针。但是，在页面级别上，数据页面不是填充了单个记录吗？添加一列是否意味着每个已经满的页面都需要拆分？

即使页面未满，也需要大量数据处理才能将该列添加到每条记录的末尾，更新所有插槽数组，然后通过任何现有索引和/或 IAM 和 GAM 页面级联所有指针更改？

我唯一能想到的是，所有新的列数据都被添加到新的页面中，没有记录的其余部分，并且在整个表树结构中添加指针以引用新的列页面。然而，这似乎会破坏空间局部性。如果是这样，即使我们没有特别请求，DBMS 是否会在幕后处理数据REBUILD？

我正在谈论带有页面的 DBMS 内存管理的位级别，并询问 DBMS 如何能够如此快速地将一列（允许或不允许 NULL 值）添加到一组现有记录中，即使这些记录已经作为一组存在数据页中的位。

fn_dblog()以这种格式显示交易 ID：

0000:00049d43

并sys.dm_tran_database_transactions以这种格式显示交易 ID：

9811233

我相信上面的例子显示了不同格式的相同交易ID。

有没有办法在两种格式之间进行转换？fn_dblog()或者这实际上是两个不同的实体——在这种情况下，是否有办法与交易相关的DMV进行匹配？

当我尝试使用一个 JSON 元素访问时，->>'elementName'我得到了一个text类型。

SELECT pg_typeof(x1->>'a'), jsonb_typeof(x2)
FROM ( VALUES
  ('{"a":5}'::jsonb, '5'::jsonb)
) AS t(x1,x2);

 pg_typeof | jsonb_typeof 
-----------+--------------
 text      | number
(1 row)

但是，jsonb表示它将数字映射到数字类型......

将文本 JSON 输入转换为 jsonb 时，RFC 7159 描述的原始类型有效地映射到本机 PostgreSQL 类型，如表 8-23 所示。

这是从文档中复制的表格，

表 8-23。JSON 原始类型和对应的 PostgreSQL 类型

JSON primitive type     PostgreSQL type  Notes
string                  text             \u0000 is disallowed, as are non-ASCII Unicode escapes if database encoding is not UTF8
number                  numeric          NaN and infinity values are disallowed
boolean                 boolean …

除了写作风格之外，还有什么优势吗？

CREATE TABLE foo (
  a int PRIMARY KEY,
  b int
);

进而，

CREATE TABLE bar (
  a int REFERENCES foo,
  c int
);

超过，

BEGIN;
  CREATE TABLE bar (
    a int,
    c int
  );
  ALTER TABLE bar
    ADD FOREIGN KEY (a)
    REFERENCES foo;
COMMIT;

我正在尝试构建一个 DDL 生成器，所以我想知道是否需要支付对列的约束（我之前生成它们的地方），或者将它们全部移到表之外？我知道这些结果产生了相同的表格，我只是想知道引擎盖下是否有任何优势——更少的沃尔玛？等等？

我不明白为什么索引重建需要对给定索引使用 Sch-M 锁。

我正在测试 SQL Server 索引并发现非常奇怪的行为。这是我的代码：

DROP TABLE IF EXISTS  dbo._Test
DROP TABLE IF EXISTS  dbo._Newtest
GO
CREATE TABLE _Test(
ID INT NOT NULL, 
UserSystemID INT NOT NULL, 
Age INT
)
GO
INSERT INTO dbo._Test
        ( ID, UserSystemID, Age )

SELECT TOP 10000000 ABS(CHECKSUM(NEWID())) % 5000000, ABS(CHECKSUM(NEWID())) % 2, ABS(CHECKSUM(NEWID())) % 100
FROM sys.all_columns
CROSS JOIN sys.all_objects a
CROSS JOIN sys.all_objects b
CROSS JOIN sys.all_objects c

; WITH cte AS (
SELECT ID, UserSystemID,  age, ROW_NUMBER() OVER(PARTITION BY ID, UserSystemID ORDER BY …

在 PostgreSQL 中，由于本文/sf/ask/698893751/中提到的原因，序列被设计为有间隙。我的问题是：是否可以通过定期（假设每天一次）检查哪些序列号未使用并将其添加回序列中以供使用，从而使序列几乎无间隙？

我假设当前 postgres 实现了一个序列作为计数器，每次访问它时它都会递增。相反，它可以通过自由值列表和计数器来实现。该序列将按如下方式工作：

# python style pseudo code

class Sequence:
    def __init__(self):
        self.free_numbers_set = []
        self.counter = 0

    def get_next_sequence_value(self):
        if not isempty(self.free_numbers_set):
            id = self.free_numbers_set.pop(0)
        else:
            id = self.counter
            id ++

        return id

    def add_free_numbers(self, column):
        for i in range(0:self.counter):
            if not i in column:
                free_numbers_set.append(i)
        free_numbers_set.sort()

每当我们需要一个新的 id 时，get_next_sequence_value()我们就会定期运行add_free_numbers(column)

更新解决一些问题

1. 对于标识列，获取当前使用的值将是微不足道的。在其他情况下，由用户提供已在使用的值的列表。
2. 需要考虑与 MVCC 的交互。人们可以潜在地实现它，以便在缺失值更新期间，序列将默认为仅递增计数器 - 这将避免冲突。

我相信这个解决方案可以提供更少的稀疏序列，这将允许用户使用更小的 id 类型（int 与 bigint），同时向后兼容当前的实现。