标签: storage

这篇文章的SQL Server的tempdb最佳实践提高性能建议我应该拆分tempdb成若干文件等于内核的数量。因此，对于 4 个内核，您将获得 4 个文件。

通过拥有更多数量的文件，您可以增加 SQL Server 可以随时推送到磁盘的物理 I/O 操作的数量。SQL Server 可以下推到磁盘级别的 I/O 越多，数据库运行的速度就越快。使用标准数据库，SQL Server 可以将其需要的大量数据缓存到内存中。由于 tempdb 的高写入特性，数据需要先写入磁盘，然后才能缓存到内存中。

虽然理论上听起来不错，但它真的像一般优化一样好吗？它是否可能仅适用于 IO 非常高的特定系统？

我在Oracle 官方文档中看到了这个声明：

在 Microsoft SQL Server 中，只有具有可变长度数据类型的列才能存储 NULL 值。当您创建一个允许 NULL 具有固定长度数据类型的列时，该列会自动转换为系统可变长度数据类型...

我从来没有在SQL Server 文档中读到过这个，也没有经历过这样的事情。相反：在 SQL Server 中，固定长度的数据类型（例如 int 和 float，还有 char）被大量使用并且即使在可为 NULL 的情况下也非常有效地存储。

这个 Oracle 声明背后有什么理由吗？！

我们有一个系统可以将一些数据归档到 PostgreSQL 数据库。我们发现由于数据库归档，PC 存储空间已满。问题是我检查了驻留在其中的数据文件/var/lib/pgsql/data/base/，它们总共大约 70 GB，而当我使用pg_dump输出文件转储所有数据库时，它们没有超过 24 GB。我在这里遗漏了什么或误解了什么？这么大的尺寸差异去哪儿了？

编辑：我确实pg_dump包含模式和数据，并带有-c允许删除和创建的选项。

编辑 2：我调查了 DB 模式文件，发现包含 24 GB（约 3.324 亿行）数据中的近 23.9 GB 的表上有一个索引。另一个表上有另一个索引，但该表为空。

编辑 3：程序定期存储大约 1500 个变量的值，我的意思是所有变量的记录时间为 0.1 秒到 1 分钟或更长时间，所以我认为这里有一个巨大的数据库访问。

编辑 4：我在这里执行第二个查询以查找模式中每个关系的大小，我发现以下内容：

• 28 GB 用于主数据表。
• 大约 42 GB 仅用于 3 个索引！24、9、9。

我的目的是我想经常（每隔几个月）进行一次备份和恢复。在进行备份和恢复时，我应该关心这些数据库索引还是只关注我的数据表？

在我们的开发设备上，我们的数据库完全位于 PRIMARY 文件组中，并且一切正常。

在我们最近从 2005 年升级到 2008 年的其中一台生产服务器上，我们注意到它的性能比预期的要慢。在这台机器上，有两个文件组 - PRIMARY 和 INDEXES。两个文件组每个逻辑卷包含 1 个文件，每个 CPU 包含一个逻辑卷。文件组共享逻辑卷（它们都分布在所有磁盘上）。

我们隔离了一些在开发机器上执行速度快而在生产机器上执行速度慢（最多慢 40 倍）的查询。原来这些查询使用的是驻留在 INDEXES 文件组中的非聚集索引。将某些查询调整为仅使用位于 PRIMARY 文件组中的聚集索引，从而使它们的时间恢复正常。

作为最后的确认，我们在同一台机器上重新部署了同一个数据库，让一切都在 PRIMARY 中，一切又恢复正常！

这是在相关机器上运行的其中一个查询的统计输出（表名已更改以保护无辜者）：

快速（主文件组中的所有内容）：

(3 row(s) affected)
Table '0'. Scan count 2, logical reads 14, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '2'. Scan count 2, logical reads 7, ...
Table '3'. Scan count 2, logical reads 1012, ...
Table '4'. Scan count …

我目前正在创建一个新数据库，以前只使用过一个数据文件和一个日志文件。我在网上做了一些关于多个数据文件的好处的研究，但我发现关于单个磁盘上多个数据文件的好处的意见不一。所以我的问题是：如果我唯一可用的磁盘是 SAN 磁盘，我会看到将数据拆分为 4 个单独文件的任何性能优势（例如多线程/并行处理）吗？使用单个文件会更好吗？

此外，将索引（可能还有存档表）分离到同一磁盘上不同文件上的自己的文件组中是否有任何性能优势？这只会提供行政利益吗？

谢谢！

MYSQL 视图占用物理空间吗？或者换句话说，MYSQL 数据库是否仅限于一定数量的视图？

我正在设置一个新服务器，并且我正在设计该服务器以实现超容量性能。规划磁盘分区方式 我想在 MBR 上使用 GPT，但不确定哪个最好。我正在使用 SAN 附加存储。

哪种分区样式（MBR 或 GPT）更适合 SQL Server 2008 R2 实现？

在 VM 上配置新的 SQL Server 时，最好将数据库、TempDB、日志和备份放在单独的逻辑驱动器上，即使底层存储相同？我知道这在物理服务器上是一个很好的做法；这种分离实际上帮助我们减少了并发 I/O 带来的痛苦。

我试图了解拥有 3 个驱动器而不是 5 个驱动器是否有意义。有人可以提供他们对这个想法的看法/建议吗？

想象一下，我在 Postgres 13 中有一个像这样的表：

CREATE TABLE public.people (
    id integer PRIMARY KEY,
    full_name character varying(255),
    bio text
);

然后，我插入一行包含足够字符的行，以便将简介写入 TOAST 表：

# insert into people values (1, 'joe user', (SELECT array_to_string(ARRAY(SELECT chr((65 + round(random() * 25)) :: integer) FROM generate_series(1,4000)), '')));
INSERT 0 1

最后，我更新该行而不更改 TOAST 列：

# update people set full_name='jane user' where id=1;
UPDATE 1

是否UPDATE更改关联 TOAST 表中的任何行（或根本需要任何写入）？

上下文：我正在处理一些每秒有数千个事务的数据库表，并且观察到服务器上的写入负载非常高。我想知道UPDATETOAST 中具有较大值但 TOAST 值本身大部分不变的元组是否会增加写入负载并且值得优化。

最近我们在对数据库进行快照时遇到错误（操作错误665）

该错误的解决方案之一是将底层磁盘类型更改为ReFS。然而，我找不到太多关于人们在 ReFS 上（而不是 NTFS）上运行 SQL Server 生产工作负载的信息。

据我了解，对于 SQL Server 2012 及更早版本 - 它使用文件流而不是稀疏文件来创建 CHECKDB 快照。ReFS 不支持，因此在 SQL Server 2012 上，ReFS 中的文件可能会导致检查 DB 时出错。

我真的很想知道是否有人在 ReFS 上运行他们的生产工作负载，以及是否有任何我们需要考虑的问题。