标签: disk-space

我们有一个应用程序，我们每隔几秒接收一次信息，我们将这些信息记录在一个称为事件的表中，该表目前重达 240 GB，这是迄今为止我们拥有的最大的。

前段时间我们删除了记录以保留特定日期的记录。不久前我们发现存储数据库的服务器正在填满磁盘，删除数百万条记录后，磁盘空间保持不变。

在网上搜索我们发现执行以下查询 ALTER TABLE tablename ENGINE = Innodb; 将释放已删除记录的已用空间。

但是我们遇到的问题是，由于我们有大于200G的表，所以该命令执行时间较长，导致新信息因阻塞而无法及时插入。

我们找到的选项如下：

• 制作数据库的副本（主 - 从），从我们在这里看到的情况来看，我们必须对主数据库进行备份并将其传递给从数据库，以便它开始从发生的地方进行复制，为此我们有详细信息是的，我们不想关闭当前的服务器，以便我们的服务保持功能，但我们也不希望丢失任何信息。我们在前一天对服务器进行了备份，我们可以使用它，但是我们如何恢复一天内未插入的信息，如果创建了该备份，那么该备份有什么内容以及从服务器是从哪里配置的？
• 备份我们当前的数据库并将其上传到新服务器，以免使用 ALTER TABLE tablename ENGINE = Innodb 命令，为此我们必须关闭服务器。
• 执行 ALTER TABLE tablename ENGINE = Innodb 命令，我们执行测试，在我们作为测试的 10 GB 表中，执行了大约 25 分钟。

有没有更优化的方法来释放空间，而不必取消我们的服务并且不会丢失信息？或者如果必须在最短的时间内完成？

此查询 ALTER TABLE tablename ENGINE = Innodb 知道它是否锁定表。

生产中的环境信息： Ubuntu Ubuntu 16.04.3 LTS mysql Distribution 10.1.21-MariaDB 所有表的类型均为 Engine = Inodb

非常感谢

我为我的大学课程安装了 SQL Server + SSMS，从那时起我的磁盘空间就丢失了（每隔一段时间，就会丢失大约 3 GB 的空间）。我强烈怀疑 SQL Server 和/或 SSMS 有问题（因为它只在我安装它们之后发生），但是我不知道如何找到丢失的空间。它是否进行了大量的日志记录？备份？不知道。

我可以在哪里找到该磁盘空间和/或检查它是否是 SQL Server 和/或 SSMS 的恶作剧？

感谢您的时间。

注意：我使用的是 SSMS 18.9.1 和 SQL Server 2019 开发人员版。我也许可以更新，但出现的任何问题都将是我因偏离官方提供的版本而造成的。

我们有一个包含大约 7 亿个条目的单个表的数据库。我们通过在服务器上添加新条目来更新数据库，然后使用 pg_dump 将服务器传输到生产服务器：

pg_dump -c 数据库 > /tmp/database_gen

（顺便说一下，我们使用 postgres 8.4）我们使用 psql 将数据库导出到生产服务器。pg_dump 生成的文件有关于如何创建和填充表的说明。

问题出在索引创建上。Postgres 填充表，然后花费数天时间创建索引。没关系，直到 postgres 无法再创建索引，因为它没有更多的磁盘空间，因为它使用大量磁盘空间来存储临时文件以进行排序和创建索引。通常数据库需要大约 200GB，但在创建索引期间，使用的磁盘空间增加到 600GB，然后在创建后又回到 200GB。

我的问题是：我们可以分几个步骤创建索引，比如为一半的表创建索引，然后添加表的其余部分并更新索引？

有没有人有同样的问题？

谢谢

After cleaning my table with DELETE FROM MyTable (and executing DBCC shrinkdatabase('MyDB') should that matter) I run the statement EXEC sp_spaceused MyTable. The results confuse me:

tableName   numberOfRows   reservedSize   dataSize   indexSize   unusedSize
---------   ------------   ------------   --------   ---------   ----------
MyTable     0              21664 KB       20672 KB   736 KB      256 KB

As you can see there are zero rows, yet there's almost 21 MB of data. My question is: what are possible causes for this situation and/or how can I further investigate …

我在 SQL Server 2008 R2 中工作并创建了一个查询，用于收集和汇总数据文件和日志文件的大小。但是，我无法找到单个 SQL 数据块在磁盘上占用多少实际磁盘空间，因此我可以将其转换为更有意义的内容。

这是脚本：

DECLARE @DataSize INT
DECLARE @LogSize INT
SELECT @DataSize = SUM(size) from sys.database_files where type_desc = 'Rows'
SELECT @LogSize = SUM(size) from sys.database_files where type_desc = 'Log'
PRINT @DataSize
PRINT @LogSize

一格空间有多大？将这两个整数变量转换为对系统管理员更有意义的变量是否容易？

是否可以为 Postgresql 后端（9.3.10 版）设置临时文件创建的位置？

这是我的场景：我的 Postgresql 数据库驻留在带有 Ubuntu 14.04 操作系统的专用 VM 中。我的 VM 带有由我的基础架构提供商提供的200GB 临时高性能 SSD 存储，用于应用程序和进程的短期存储。这是它的样子：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       221G  9.9G  200G   5% /mnt

我的磁盘空间不足，必须运行一些分析查询，由于临时文件的创建，这些查询可能使我的磁盘已满。

除了采取删除日志条目以释放更多空间或temp_file_limit在 postgresql conf 中设置等措施外，我还想知道是否可以设置临时文件的位置。毕竟，我有 220GB 可用于这些场景，所以一定要好好利用它们（交换空间也在这里设置）。

由于我是一名新手 DBA，因此我可以通过一个说明性示例来说明如何进行设置。

我刚刚在我的数据库上运行了一份磁盘使用情况报告，发现它在过去一个月中增长了很多，目前在数据上使用了 3.98 GB（上个月大约是 300 MB）

但是，当我按表运行磁盘使用情况报告时，我发现表中的空间使用情况目前与 3.98 GB 相差甚远

我如何才能找到正在使用剩余空间的内容，以便将其加起来为 3.98 GB？

编辑

这是“收缩文件”对话框的屏幕截图：

我们的服务器管理员要求我释放 SQL 服务器上的磁盘空间，因为 SQL 数据文件所在的驱动器的使用率为 97%。

我发现了一张失控的桌子。它现在包含超过 3 亿行，所以我将设置一项工作以在一夜之间删除这些行。

• 我有什么选择可以释放磁盘空间？
• 删除这些行会释放空间供其他表使用吗？

我想避免 SHRINKFILE，因为不推荐。

我的数据库很大，最近我注意到几个月前添加的新表是罪魁祸首。

这是表脚本。

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Entry_tracker](
    [S.Number] [int] IDENTITY(1,1) NOT NULL,
    [EntryId] [varchar](50) NOT NULL,
    [EventNumber] [varchar](18) NOT NULL,
    [Data] [varbinary](max) NOT NULL,
    [TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Entry_tracker] ADD  CONSTRAINT [DF_Entry_tracker_TrackDateTime]  DEFAULT (getdate()) FOR [TrackDateTime]
GO

我收集了这张表的信息，了解到该表大约有1600万行，表大小为1.4TB。

尽管如此，我认为桌子的大小对于没有。的记录。

应用程序不查询该表。它只是存储来自另一个表的相同条目的不同版本。

我检查了碎片信息，它显示平均碎片为 0，平均空间使用率为 93%。

由于我使用的是 SQL Server 2016，我虽然可以使用表压缩，因此尝试sp_estimate_data_compression_savings估计可能的空间节省。但是，结果显示没有节省。

size_with_current_compression_setting(KB) 等于 size_with_requested_compression_setting(KB)

任何人都可以指导我找到这张表的问题吗？

这非常重要，因为这会占用大量磁盘空间。

感谢你的帮助。

我目前在一张表上大约有 70 亿行，并且接近整个数据库的最大磁盘空间。

我需要开始将一个大表上的新数据保存到新磁盘。

我已经看过分区datetime，这似乎是显而易见的选择 这是我们在 6 个月内获得新服务器之前的临时解决方案，但需要“现在”解决方案。

我将如何实现这一目标？我可以实施手动分区以便所有新数据都转到新磁盘吗？

我所看到的一切都需要创建类似于每月选项的内容，而我只想将所有新内容放在新磁盘上。

一种选择是按月拆分现有数据，然后手动移动分区。

我什至不确定这是否可行，因此希望获得有关实现上述目标的最佳解决方案的一些反馈。

SQL Server 2017 企业版。