标签: storage

我们在 Postgres 中有一个 2.2 GB 的表，其中有 7,801,611 行。我们正在向它添加一个 uuid/guid 列，我想知道填充该列的最佳方法是什么（因为我们想NOT NULL向它添加约束）。

如果我正确理解 Postgres，更新在技术上是删除和插入，所以这基本上是重建整个 2.2 gb 表。我们还有一个奴隶在运行，所以我们不希望它落后。

有没有比编写一个随着时间慢慢填充它的脚本更好的方法？

在 PostgreSQL 文档中，据说整数数据类型可以存储在两字节、四字节或八字节的空间中。我的数据库中表的一列包含一个一字节整数值，我希望它以一字节数据类型存储。

1. 在 PostgreSQL 中是否有使用单字节整数数据类型的扩展或方法？
2. NUMERIC(1,0) 是多少字节？

在生产 SQL Server 上，我们有以下配置：

3 台 Dell PowerEdge R630 服务器，合并到可用性组中
所有 3 台都连接到作为 RAID 阵列的单个戴尔 SAN 存储单元

有时，在 PRIMARY 上，我们会看到类似于以下内容的消息：

SQL Server 在数据库 ID 8 中
的文件 [F:\Data\MyDatabase.mdf] 上遇到了 11 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄为 0x0000000000001FBC。
最近一次 long I/O 的偏移量为：0x000004295d0000。
长 I/O 的持续时间为：37397 毫秒。

我们是性能故障排除的新手

解决此与存储相关的特定问题的最常见方法或最佳实践是什么？

必须使用哪些性能计数器、工具、监视器、应用程序等来缩小此类消息的根本原因？

可能有一个扩展事件可以提供帮助，或者某种审计/日志记录？

更新：添加了我自己的答案（见下文），解释了我们为解决问题所做的工作

我正在尝试使用两个原始（即未格式化）分区创建数据库。

Microsoft Docs 声明您可以执行此操作，您只需指定原始分区的驱动器号，如下所示：

CREATE DATABASE DirectDevice 
ON (NAME = DirectDevice_system, FILENAME = 'S:')
LOG ON (NAME = DirectDevice_log, FILENAME = 'T:')

但是，SQL Server 2017 返回此错误：

消息 5170，级别 16，状态 4，第 1 行
无法创建文件“S：”，因为它已经存在。更改文件路径或文件名，然后重试该操作。
消息 1802，级别 16，状态 4，第 1 行
创建数据库失败。无法创建列出的某些文件名。检查相关错误。

文档的相关部分指出：

如果文件位于原始分区上，则 os_file_name 必须仅指定现有原始分区的驱动器号。每个原始分区上只能创建一个数据文件。

是的，驱动器 S: 和 T: 都是未格式化的原始分区，它们确实存在于我的系统中：

DISKPART> 详细分区

分区 4
类型：ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
隐藏：否
要求：否
属性：0000000000000000
以字节为单位的偏移量：999934656512

  卷 ### Ltr 标签 Fs 类型大小状态信息
  ---------- --- ----------- ----- ---------- ------- ---- ----- --------
* 第 6 卷 T RAW …

我在生产数据库中有一个表，其大小为 525 GB，其中 383 GB 未使用：

我想回收其中的一些空间，但是，在弄乱生产数据库之前，我正在测试数据库中数据较少的相同表上测试一些策略。这个表有一个类似的问题：

关于表的一些信息：

• 填充因子设置为 0
• 大约有 30 列
• 其中一列是图像类型的 LOB，它存储的文件大小从几 KB 到几百 MB
• 该表没有任何与之关联的假设索引

服务器正在运行 SQL Server 2017 (RTM-GDR) (KB4505224) - 14.0.2027.2 (X64)。数据库正在使用SIMPLE恢复模型。

我尝试过的一些事情：

• 重建索引：ALTER INDEX ALL ON dbo.MyTable REBUILD. 这产生了微不足道的影响。
• 重新组织索引：ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON). 这产生了微不足道的影响。

• 将 LOB 列复制到另一个表，删除该列，重新创建该列，并将数据复制回来（如这篇文章所述：释放未使用的空间 SQL Server 表）。这减少了未使用的空间，但似乎只是将其转换为已用空间：

  

• 使用 bcp 实用程序导出表、截断它并重新加载它（如这篇文章所述：如何为表释放未使用的空间）。这也减少了未使用的空间并增加了与上图类似的程度。

• 即使不推荐，我也尝试了 DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 命令，但它们对未使用的空间没有任何影响。
• 跑步DBCC CLEANTABLE('myDB', 'dbo.myTable')没什么区别
• 在保持图像和文本数据类型以及将数据类型更改为 varbinary(max) 和 …

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

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

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

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

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

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

我有一个非常频繁更新的表，其中包含 2.4 亿行（并且还在增长）。每三小时插入 150 万行，删除 150 万行。当我将集群移动到 SSD 时，批量插入（使用复制）时间从 22 分钟减少到 2.3 分钟。删除时间也得到改善。我计划每两小时或每小时进行一次批量更新。

虽然现在的性能（在 SSD 之后）与更频繁的更新兼容，但我读过一些关于 SSD 死亡的恐怖故事，因为 NAND 耐久性有限加上写放大。由于 SSD 价格昂贵，我想尽可能地将它的消亡推迟到未来。因此我的问题是：在删除和随后的真空中磁盘文件到底发生了什么？我猜有两个磁盘写入，一个将行标记为已删除，另一个在清理时将其标记为可覆盖。如果不是删除和清空，而是在每次批量插入/删除时对表进行分区创建和删除表，我会尽量减少 SSD 的磨损吗？

我在 Postgres 数据库中有 4 亿行，表有 18 列：

id serial NOT NULL,
a integer,
b integer,
c integer,
d smallint,
e timestamp without time zone,
f smallint,
g timestamp without time zone,
h integer,
i timestamp without time zone,
j integer,
k character varying(32),
l integer,
m smallint,
n smallint,
o character varying(36),
p character varying(100),
q character varying(100)

列e、k和n都是 NULL，它们根本不存储任何值，此时完全没用。它们是原始设计的一部分，但从未被移除。

编辑 - 大多数其他列都是非 NULL。

问题：

1. 如何计算这对存储的影响？它是否等于列的大小 * 行数？

2. 删除这些空列会显着提高该表的性能吗？页面缓存能够容纳更多行吗？

以前的高级 DBA 为我们整个公司的每个 SQL Server 中的所有驱动器设置了挂载点。新的高级 DBA被挂载点吓坏了想改变我们的标准（我认为主要是因为他没有使用它们的经验）。

根据大量 Internet 搜索的结果，我找不到任何（SQL Server 2000 后）不使用挂载点的理由。

有没有人知道有关此主题的 Windows 操作系统限制？

• 我最近经常听到“操作系统无法识别挂载点”的说法。（不真实，基于我对我们使用的 Windows Server 版本的研究）。

是否有任何基于证据或经验的理由不将挂载点与 SQL Server 一起使用？

• 假设用完驱动器号对我们来说不是问题。

我的理解是挂载点对于隔离工作负载非常有用。

任何人都可以确认或反驳我的理解，挂载点实际上比一个驱动器更有效地隔离/隔离不同类型的数据和日志文件（系统数据库文件、用户数据库文件、tempDB）的数据文件、日志文件和 tempdb ?

想象一下您的需求是您有 3 个巨大的表（结构化数据），每个表中有 300 亿行（总大小为 4TB），并且您的许多并发用户（它们是远程 LAN 机器上的并行操作系统线程）需要读取一部分数据通过他们的 SELELCT WHERE GROUPBY 查询和高并发，比如 10,000 次并发读取，同时用户也需要将（无更新）数据插入到这些表中，高并发也像 2000 个并发写入者（遍布数据中心 LAN 网络） . 用户希望从这个存储中尽可能快地读取和插入，每次读取和写入将发生在 ms 到 1 秒的范围内。

你推荐什么技术来满足这样的要求？是否有任何数据存储或键值存储可以做到这一点？云不是一种选择。

一些说明：

用户不必立即查看数据，最终的一致性是可以接受的。数据是通过存储可以提供的任何驱动程序访问的，用户再次只是在数据中心的远程机器上运行的线程。查询大多类似于 SELECT WHERE GROUPBY。

数据为表格格式，每行约 60 个字节。

没有云选项，我不能使用 DynamoDB 或类似的解决方案。我必须能够在数据中心内部托管它。

表的所​​有数据都可以随时读取，使用模式不可预测。没有连接或超长查询。不需要 DR，但需要合理的 HA，但不必太花哨。每个读者都根据它的 where 子句获得一批行，而行并不真正相关。我们可能可以为每一行设置固定长度，但我希望存储层会担心它。

此外，我最关心的是并发读取时发生的所有并发写入。

非常感谢您对此的见解。

更重要的是，我有三个这样的表，每 300 亿行包含不同的对象类型