标签: disk-space

我有一个带有不可为空VARCHAR(MAX)列的表，其中每一行都包含一个空字符串（第三方数据库，因此我无法更改它）。我看到了大量的空间使用，超过 15GB 的 100 万行。

如果我运行以下查询，我会看到 LOB_DATA 的大量 used_pa​​ges，即使该列中没有数据。不包括VARCHAR(MAX)行大小低于 8000 字节。

 SELECT o.name AS table_name,p.index_id, au.type, au.type_desc, au.total_pages, au.used_pages, au.data_pages
 FROM sys.allocation_units AS au
   JOIN sys.partitions AS p ON au.container_id = p.partition_id
   JOIN sys.objects AS o ON p.object_id = o.object_id
 WHERE o.name = 'table
 ORDER BY o.name, p.index_id;

type    type_desc             total_pages   used_pages  data_pages
1   IN_ROW_DATA 23258             23252           23188
2   LOB_DATA              1880733             1880455             0
3   ROW_OVERFLOW_DATA   0             0           0

评论更新：

• 该表是一个存档表，因此数据不应更改（仅插入）
• 我在一个单独的数据库（同一个服务器）中有一个相同的表，其中有类似的数据，但没有出现这个问题
• 重建索引没有帮助
• large_value_types_out_of_row 为 0
• DBCC …

我们使用的是 PostgreSQL v8.2.3。我们是一个基于 web 的应用程序，我们使用 pgpool-II v 2.0.1 纯粹是为了连接池（我们不使用 pgpool 的其他功能，如复制、负载平衡等）。

最近，在我们的生产服务器中，数据库磁盘空间出现了意外的急剧增长。在短短 2 天内，数据库大小从 6 GB 增长到 14 GB。

然后我运行以下查询来查找数据库中前 20 个最大关系的大小：

SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class
C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN
('pg_catalog') ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 20;

我在这里没有发现任何问题。甚至我可以说上述命令的“total_size”之和小于数据库本身占用的大小。我正在使用以下命令来查找数据库的大小：

select oid, datname, pg_database_size(datname) as actualsize,
pg_size_pretty(pg_database_size(datname)) as size from pg_database order by
datname;

我也曾经使用以下命令物理检查占用的数据库大小：

du -sh /usr/local/pgsql/data/base/2663326

然后我从位置“ /usr/local/pgsql/data/base/2663326 ”开始按降序物理列出文件大小。这里，“2663326”是我的数据库的 OID。

[root@dbserver 2663326]# …

我有一个表，其中列中有很多 NULL 值。但是有些列根本不包含 NULL（尽管可以为空）。将所有这些列声明为 SPARSE 有什么缺点吗？

SQL Server 新手在这里。我是一个 MySQL 人。我正在为他们的 2008 SQL Server 中的客户查看一些东西，需要一些建议。设计数据库的人选择记录疯狂数量的东西并且从不刷新这些日志表。

最大的餐桌商店完成 XML来自应用程序和 eBay 等网站的 API 之间交易的文档。我只能假设大约 230 GB 的数据库会影响性能。我猜这些表不会在应用程序中查询，但即便如此，我也不喜欢如此庞大的数据库的想法。清除日志表后，我预计总剩余大小约为 30GB。

我想就如何解决这个问题提供一些建议。从我对这个主题的了解来看，删除一堆数据后，数据库文件不会自动缩小大小。我还读到缩小和重新索引是不好的。

• 这个大型数据库是否会损害其他表的性能？
• 我应该做些什么吗？
• 我怎样才能安全地做一些事情来提高性能？

我们有一个相当大的 MS SQL 2008R2 数据库，它驻留在 SSD 驱动器上。驱动器本身只有大约 110Gb 的空间，并且数据库文件是驱动器上唯一的文件。

数据库处于“简单”恢复模式，只有两个文件，.MDF 和.LDF。

磁盘现在几乎已满：MDF 目前的大小为 109Gb。但是，SSMS 告诉我有将近 18Gb 的“可用空间”（在“常规”属性页面中），如果我完成Shrink文件的操作，它还会告诉我有 18Gb 的可用空间。SSMS 还告诉我数据库大小约为 132Gb，这让我感到惊讶 - 这不适合驱动器！

从我所读到的，这shrink是一个非常糟糕的主意。但是，我开始看到复制错误 ( could not allocate space for object)。我们之前曾尝试缩小数据库，但在几个小时内，文件又恢复到原来的大小。

我们应该如何进行 - 鉴于显然有 18Gb 的可用空间，SQL 是否应该自动使用该可用空间？或者就这么简单：我们真的需要更多的磁盘空间？

我正在使用 innodb_file_per_table 运行 MySql innodb。

作为日常脚本，我想为一组表创建一个新分区，并删除昨天的分区。需要运行什么命令来删除旧分区以释放磁盘空间？我希望避免系统因数据库磁盘使用而耗尽磁盘空间。我还想避免关闭 Mysql。

编辑：我读过丢弃表空间应该删除占用大部分空间的 .ibd 文件。

ALTER TABLE tbl_name DISCARD TABLESPACE;

但是，在分区表上使用此命令存在一个已知错误。

在另一个问题中，我了解到我应该从我的一个表中优化布局以节省空间并获得更好的性能。我这样做了，但最终得到了比以前更大的表，并且性能没有改变。当然我做了一个VACUUM ANALYZE. 怎么会？

（我看到如果我只索引单列，索引大小不会改变。）

这是我来自的表（我添加了尺寸 + 填充）：

                               Table "public.treenode"
    Column     |           Type           | Size |          Modifiers
---------------+--------------------------+------+-------------------------------
 id            | bigint                   | 8    | not null default nextval( ...
 user_id       | integer                  | 4+4  | not null
 creation_time | timestamp with time zone | 8    | not null default now()
 edition_time  | timestamp with time zone | 8    | not null default now()
 project_id    | integer                  | 4    | not null
 location      | real3d                   | 36   | …

我想知道如何计算文件组中每个文件消耗的数据分布，回到存储它的索引（HEAP、CLUSTERED、NONCLUSTERED）。我的目的是定义哪些 I/O 去磁盘上的哪个位置。

我data_space_id从 开始sys.indexes，显示已使用、已分配的页面；和data_space_id大小从sys.filegroups. 所以我到达了用于将数据存储到文件组内的文件的加权（按可用空间比率？）算法生效的地方。我可以加入sys.database_files使用data_space_id.

从sys.dm_allocation_units （通过object_Id和连接到索引index_Id）我得到partition_ID；加入sys.dm_partitions建议行数，使用和分配的页面，允许计算也显示每个分区的可用内容。无法分区到文件...？

我有一个查询，我根据文件组中每个文件的已使用页面的比率将 DATA 分配给 FILE，将该比率应用于存储在文件所属的文件组上的索引数据。

是否有更好的方法将表/索引数据向下钻取到文件级分配？（测量而不是计算？）

对于 indid = 0 或 indid = 1，dpages 是使用的数据页数。
对于 indid > 1，dpages 是使用的索引页数。

对于 indid = 0 或 indid = 1，used 是用于所有索引和表数据的总页数。
对于 indid > 1，used 是用于索引的页数。

对于 indid = 0 或 indid = 1，reserved 是为所有索引和表数据分配的页数。
对于 indid > 1，reserved 是为索引分配的页数。

查询语句：

Select  T.Name …

有没有一种方法可以让我在 sql server 2012 中获取报告或创建自定义报告，它可以每天两次或一次更新我列出的驱动器的可用磁盘空间和实际磁盘空间。

我需要这个是因为我的客户需要查看一个月内的磁盘空间使用情况才能看到所需的模式。

谢谢！

由于磁盘限制，我最近进行了一项练习，以释放生产数据库 (SQL Server 2008 R2) 中的一些空间。特别是一张表就占据了 98% 的数据库。不需要的记录被识别出来，占数据的 1/3（大约 160GB 或 450GB）。

所以我在不同的磁盘上创建了一个数据库，创建了一个具有相同架构的表，唯一的区别是创建了一个 ID 列，而不是IDENTITY. 我将其称为存档，将原始称为源。根据 SSMS，Original 有 PK 索引和另外两个小索引，总计 19MB。存档只有 PK 索引，因为它不会被查询。

我一次将数据分批传出 1000 行，以尽量减少对生产的影响。几个小时后，存档上的磁盘空间也用完了，所以当数据库达到 145GB 时我停止了传输，这代表了 800,000 行。

然后我开始删除源表，确保只删除存档的内容。这运行了一夜，并在交易开始前停止，最终从原始表中删除了 550,000 行。

根据存档，这应该是大约 (145GB / 800000) * 550000 ~= 100GB。但是源数据库中的可用空间只有45GB！

我已经做了明显的谷歌搜索和检查 DMV，但我找不到任何有用的东西，然后我承担了比较所有数据的数据长度以查看问题是否出在那里的任务。当我们使用 XML 列时，我的想法是删除的列由于其内容而代表较小比例的存档数据。这变得更加混乱，以下是结果：

• 在存档和源中，（存档图）= 69.24362996 GB
• 在存档和源中，（源图）= 69.24362996 GB
• 在存档中但不在源中（从源中删除）61.09401641 GB
• 存档总数 130.3376464 = GB

所以这证明存档的数据大小与源（前两名）匹配，更重要的是我怀疑删除的 550000 行代表磁盘空间的一部分比剩余的 250000 更小。

但是删除的记录加起来比数据库中释放的 45GB 多出 16GB。而且存档被计算为具有 130GB，尽管大小为 145GB，因此再次出现 15GB 的赤字。

这是我正在努力弄清楚的。我目前的理论，虽然我不知道如何证明，但删除的数据（哪个日期分布在表格中）已从页面中删除，留下一些不符合标准的数据，所以如果这些页面已满 8kb，我们删除了一些代表其中 2kb 的数据，这就是数字不匹配的原因，仅释放了 45GB …