问题[disk-space](dba)

我有这两个相同的表：

                  Table "public.region"
   Column    |   Type   | Collation | Nullable | Default 
-------------+----------+-----------+----------+---------
 r_regionkey | integer      |           | not null | 
 r_name      | char(25)     |           |          | 
 r_comment   | char(152)     |           |          | 
Indexes:
    "region_pkey" PRIMARY KEY, btree (r_regionkey)

和

                  Table "public.region2"
   Column    |   Type   | Collation | Nullable | Default 
-------------+----------+-----------+----------+---------
 r_regionkey | smallint |           | not null | 
 r_name      | text     |           |          | 
 r_comment   | text     |           |          | 
Indexes:
    "region_pkey" PRIMARY KEY, btree (r_regionkey)

我正在使用smallintandtext为了节省空间，但奇怪的是结果如下：

select pg_size_pretty(pg_table_size('region'))

返回8192 bytes时

select pg_size_pretty(pg_table_size('region2'))

返回48 kB。

为什么要region2占用更多空间，即使我使用的是smallint代替integer和text代替char(n)？

我们PostgreSQL 11在CentOS 7服务器下运行。最近，我们在日志中有几个警告导致 PostgreSQL 服务器崩溃：

2022-05-09 23:26:29 EDT pg_restore      db123      132.132.132.32  postgres        ERROR:  could not extend file "base/71592268/71621568": No space left on device
2022-05-09 23:26:29 EDT pg_restore      db123      132.132.132.32  postgres        HINT:  Check free disk space.
(...)
2022-05-09 23:26:33 EDT                                 DETAIL:  Could not open file "pg_notify/0000": No space left on device.
2022-05-09 23:26:34 EDT                                 LOG:  database system is shut down

目录下有几个数据库/var/lib/pgsql/11/data/base/：

# du -h /var/lib/pgsql/11/data/base/
7.7M    /var/lib/pgsql/11/data/base/1
7.7M    /var/lib/pgsql/11/data/base/13877
8.1M    /var/lib/pgsql/11/data/base/13878
0       /var/lib/pgsql/11/data/base/pgsql_tmp
61M     /var/lib/pgsql/11/data/base/852671
166M    /var/lib/pgsql/11/data/base/852672
699M    /var/lib/pgsql/11/data/base/852673
83M     /var/lib/pgsql/11/data/base/852674
14M     /var/lib/pgsql/11/data/base/852675
476M    /var/lib/pgsql/11/data/base/852676
131M    /var/lib/pgsql/11/data/base/852677
14G     /var/lib/pgsql/11/data/base/1102146
9.9M    /var/lib/pgsql/11/data/base/30205118
9.4M    /var/lib/pgsql/11/data/base/34117470
274M    /var/lib/pgsql/11/data/base/71255881
9.2G    /var/lib/pgsql/11/data/base/71501647
9.2G    /var/lib/pgsql/11/data/base/71592267
9.8M    /var/lib/pgsql/11/data/base/60242430
9.2G    /var/lib/pgsql/11/data/base/71423479
8.1G    /var/lib/pgsql/11/data/base/71423480
6.5G    /var/lib/pgsql/11/data/base/71592268

问题：

1. 在不访问 PostgreSQL 服务器的情况下，如何知道哪个基目录对应哪个数据库名称？
2. 一旦我们知道哪个目录分配给哪个数据库，删除它是否安全？

如果我在同一张表的同一列中有同一行，我每天写入 4 个字节（整数）100,000 次，那会磨损 SSD 吗？对于 SSD 来说，每天 400 kb 不算什么，但将它写入同一个存储单元就会弹出它。

• Postgres 数据库管理系统是否以某种方式在后台处理这些单元？
• 还是现代 SSD 芯片在硬件中做到这一点？
• 还是它们都被写入同一个存储单元，我们只是随着时间的推移交换死掉的 SSD？

关于作为独立实例运行的 Oracle 数据库企业版版本 19.10.0.0.0 的问题。

我有一张有数十亿行的表。该表始终将 PCTFREE 设置为 10。

事实证明，我们只在这张表上执行过插入，没有更新，没有删除。我想通过将 PCTFREE 降低到 0 来节省磁盘空间。

据我了解，如果我只是执行 ALTER TABLE x PCTFREE 0 那么在我们的例子中，只有未来分配的块会受到影响。但是所有数以百万计的现有块永远不会被填充超过 90%，因为我们永远不会更新或删除这些行。

有没有办法让所有旧块“重新评估”并在我降低 PCTFREE 后重新放回空闲列表？

我不希望移动所有数据（例如，使用 CTAS，或 expdp+impdp，或删除+插入每一行，或 dbms_redefinition），因为表太大以至于这将永远花费和/或使用大量的中间空间. 我只需要数据库知道现在可以在旧块中放置更多行。这可能吗？

由于 10GB 的限制，如何使用最少的数据库文件空间在 Mircosoft SQL Server Express 上重建索引

我的数据库文件大小为 7GB，但我有两个索引位于两个非常分散的最大表上

如果我尝试重建索引 PK_Sale_Dtl 文件大小膨胀到 10GB 并且重建失败并且我无处可去，但是如果我删除索引并重新创建它，文件几乎不会增加

为什么是这样？哪个更好地重建或重新创建索引？

问题

我们有一个带有 1TB 附加磁盘（在 Azure 上）的 Sql Server 2014，磁盘空间不足。我们还剩下大约 20GB（可能还有几周的空间）。因此，我们需要将一些数据从 CURRENT 磁盘移到 NEW 磁盘上。

细节

服务器：

Microsoft SQL Server 2014 - 12.0.2548.0 (X64) 
    Jun  8 2015 11:08:03 
    Copyright (c) Microsoft Corporation
    Web Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

MS-SQL 2014 安装在经典Azure VM 上。此 VM 位于经典VNET 中。存储盘也很经典。因此，我们不能只扩展现有磁盘。MS-Support 表示，如果我们希望利用现代 Azure 存储允许调整磁盘大小、使用更新的 SSD 磁盘等，我们需要更新所有这些。TL;DR; 我们不能让这个离线几个小时，包括通过 IP 地址与 VM 通信的所有其他子系统。现在，不要把这变成一场盛大的狂欢......这是我们被赋予的工作，并且需要稍后解决所有这些问题。

所以现在，一个想法尝试和利用 FILEGROUPS 并将一个或多个表移动到 FILEGROUP 并将这个 FILEGROUP 推送到我们附加的另一个 DISK 上。

所以这里的问题是：

• 首先，这真的是一个非常疯狂和蹩脚的想法吗？
• 如果它是废话但没问题，那么使用 FILEGROUPS 实际上会将数据从当前磁盘移动到新磁盘（这会释放几乎已满的当前磁盘上的一些磁盘空间）？
• 如果这仍然可能，移动这些表是否意味着数据被锁定/不可用......这意味着仍然回到我们最初的问题:(
• 日志呢？移动这些数据意味着日志只是得到这个的副本？（我相信我们正在做每小时和每周的备份）。

如果数据很小也没关系，但这里快速浏览一下我们的一些表......

第一个表很大（相对于其余数据）。750GB左右。

我正在考虑在结果图像中移动第 4 行的第 2 行、第 3 行。还记得我说过的基础设施都是旧经典的东西吗？这意味着 HD 既旧又慢，因此复制数据也可能需要一些时间。

例如，我只是尝试将.mdf's（此数据库有 1 个主 mdf 和 2 个其他小 mdf）从 OLD 复制到新磁盘。有一个 24 小时的快速 ETA。

让网站离线几个小时是完全可以接受的。当我们的客户睡着时，我们可以将东西离线。但是...... 24小时......那很痛。24 小时的想法是一个简单的测试：

• 创建新的 2TB 磁盘（如果可能）
• 关闭sql服务器。
• 将 mdf + 日志文件复制到新磁盘。（24小时左右）
• 将文件组从旧位置指向新位置
• 再次启动sql server。

现在，我们对想法持开放态度，我知道堆栈交换不是“意见”的网站，所以我试图通过建议的答案来保持目标并获得反馈......但我们是开放的其他解决方案以减少离线时间。

所以 - 任何人都可以帮忙吗？

更新 1

这是此数据库的当前文件的屏幕截图。

我在/根分区上有一个 postgresql 数据库（63GB 中使用了 61GB），所以我要求 VPS 提供商添加更多磁盘（50GB 到/mnt/vdb1）

如何将另一个数据目录添加到该新分区（使用符号链接或其他东西）？

这样新创建的表不使用/var/lib/postgresql/10/main/base而是使用/mnt/vdb1。我一直在寻找，但似乎多个数据目录仅在旧PostgreSQL 6/7上可用？

使用 Postgres 11.1，我一直在尝试确定/估计表中将由 VACUUM FULL 恢复的“浪费”空间量。我的计划是使用 pg_stat_get_live_tuples (L)、pg_stat_get_dead_tuples (D) 和 pg_total_relation_size (S)，然后估计浪费的空间为 (D / (L+D)) * S。

但是，这似乎不起作用。在调查为什么不这样做时，我进行了以下设置：

CREATE TABLE sam_silly(txt TEXT);
INSERT INTO sam_silly VALUES('one');
INSERT INTO sam_silly VALUES('two');
INSERT INTO sam_silly VALUES('three');
INSERT INTO sam_silly VALUES('four');
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;
INSERT INTO sam_silly SELECT txt || '+' FROM sam_silly;

然后我根据这些功能对空间进行了初步统计。结果符合预期（有一百万行，即 2^20 行）：

select pg_total_relation_size(c.oid) AS size, pg_stat_get_live_tuples(c.oid) AS live, pg_stat_get_dead_tuples(c.oid) AS dead
FROM pg_class c where relname='sam_silly';

• 47308800, 1048576, 0

然后我删除了一半的表：

delete from sam_silly where txt like 'one%' or txt like 'three%';

立即重复上面的查询给出了我期望的结果：

• 47308800, 524288, 524288

一半的数据是活的，一半是死的。

然后我运行“分析”，这就是事情变得奇怪的地方：

• 47316992, 524288, 0

空间略有上升，但现在没有死行！

我也试过“真空”：

• 47316992, 524264, 0

变化不大。

最后，在 VACUUM FULL 之后，它的行为再次符合我的预期：

• 23519232, 524264, 0

现在没有死元组，而且空间已经恢复。

真正的数据库打开了 autovacuum，所以它可能会清理我感兴趣的表。但看起来清理会导致它将死元组的数量设置为 0，即使仍然有很多“浪费”的空间。

有没有办法找出/估计在这种情况下“浪费”了多少空间，当 pg_stat_get_dead_tuples 返回零时，即使它没有回收先前报告的死元组使用的空间？

相关情况下的确切版本：“x86_64-pc-linux-gnu 上的 PostgreSQL 11.1，由 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28) 编译，64 位”

我查询了 sp_databases，所有数据库占用的空间总和为 380Gb。托管实例的总分配空间为 800Gb。

但是，询问基础设施团队发现我们只剩下 40GB 的空间。

我在这里弄错了什么？如何检查 MI. 中的总已用空间和剩余空间？

在生产服务器（Microsoft SQL Server 2014）中，文件MSDBData.mdf膨胀到超过 450 GB，几乎占用了服务器中的所有空间（仅剩下 38 GB）。

首先，我在MSDB网络共享上创建了一个备份（通过SSMS -> 活动 -> 备份）。然后我尝试减小文件的大小（通过 SSMS -> 活动 -> 收缩 -> 文件），但是收缩停止并且没有释放磁盘空间。缩小的对话窗口从几个小时开始就被冻结了。

在 SSMS 的活动监控中，在监控收缩的过程中似乎处于SUSPENDED状态。

在事件查看器中有几个事件

IE

(source MSSQLSERVER, eventid 847) beginning with

 1. Time-out occurred while waiting for latch: class 'FGCB_ADD_REMOVE'
 2. Time-out occurred while waiting for latch: class 'FCB'

问题：关闭SSMS的对话窗口以停止MSDB的收缩是否安全，以便进行进一步调查？