标签: disk-space

我一直在努力让我们的数据库客户端主动避免填满他们正在使用的数据库所在的分区。

由于我们所有的客户端都与数据库管理器在同一台主机上，因此对于用户创建的表空间来说应该很容易；客户端可以查找表空间的文件系统路径（在 spclocation 中），并使用操作系统调用来检查有多少可用空间：

adb=> select * from pg_tablespace;

  spcname   | spcowner |    spclocation    |       spcacl        
------------+----------+-------------------+---------------------
 pg_default |       10 |                   | 
 pg_global  |       10 |                   | 
 adb        |  2033793 | /database/adb     | {adb=C/adb}

我无法从客户端看到如何获取全局表空间存储位置的路径；在上面的查询中为它返回一个空字符串。

不幸的是，我们在该领域有许多遗留系统使用在全局表空间中创建的特定数据库，将它移到用户创建的表空间中将是一项巨大的努力。

希望我只是错过了一些非常简单的东西。

我有一个大约 6Gb 的备份。它是原始文件的“轻量级”备份（清除了日志表），大约为 14Gb。

我尝试在我的 SQL Express 本地服务器上恢复备份。它失败并显示类似 : 的消息System.Data.SqlClient.Error: insufficient disk space。它要求 227,891,019,776 字节，这绝对是疯狂的，几乎和我的整个硬盘一样大。

正如在其他网站上发现的那样，我尝试了RESTORE FILELISTONLY FROM DISK = 'backupfile.bak'.

数据文件（列Size）的大小为 6,888,226,816，但日志文件的大小为 221,006,987,264。该列BackupSizeInBytes返回 6,259,736,576 和 0。

因此，如果我理解正确，则在继续之前，恢复检查我是否有足够的空间来恢复日志文件的“理论”大小，而忽略实际的日志文件大小？

我怎样才能绕过它？获得备份有点困难，所以如果我能在不返回生产服务器的情况下解决我的问题，那就太好了。

谢谢 ！

哦顺便说一句，我在 SQL Server 2008 R2 Express 上。

我看到了这个问题Bit vs. Boolean columns。

对于 Postgres，我问自己同样的问题：一位整数列是否占用了布尔值列的相同磁盘空间？在大表（约 50 列 x 约 5000 万行）中，哪一个表现最好？我怎样才能找到这个？

我有一个客户端服务器，在这个实例上有大约 15 个数据库，数据总量约为 100 GB。其中一个数据库用于 sysaid 应用程序。他的临时数据库文件是一个 mdf 一个 ndf，当然还有一个 ldf。mdf 与其他 mdf 位于同一驱动器上，如果 ldf 文件也是如此。

当我设置自动增长属性时，我知道我应该将其保持为不受限制的增长，但是当我需要在 % 或 MB 的自动增长之间进行选择时，该选择什么？我怎么知道要配置什么号码？

提前致谢！

有没有办法计算全文搜索目录所需的物理驱动器空间？空间很便宜，但我想知道我在做什么。

我正在查看一个包含大约 200 篇长度不等的文章的表格。我想索引标题字段和文章的正文。

更新： 我有点想预测未来。例如200篇文章，标题是varchar(500)，文章正文是varchar(max)。那么，在不创建索引的情况下，是否可以估算全文搜索目录的大小？

我正在使用 PostgreSQL (8.4) 来存储由频繁插入的应用程序生成的数据（在下面描述的表结构中）。

数据库随着时间不断增长，并且由于新数据比旧数据更相关（在这个特定的应用程序中），删除旧行是一个合理的解决方案（基于 lowerid或 old input_datetime，或多或少相同） .

为了防止与此数据库（此服务器上运行的唯一数据库）相关的问题影响系统的其余部分，我将 PostgreSQL 数据目录放在其自己的分区（在 Linux 系统上为 ext3）。然而，当这个分区变满时，这会导致许多问题。

我正在考虑定期删除旧数据（例如DELETE FROM data_group WHERE id <= ...通过 cron 作业）来解决这个问题。

首先，我的理解VACUUM（由 auto-vacuum 执行，已开启）是，虽然它不一定将磁盘空间返还给操作系统（就像VACUUM FULL那样），但它仍然允许将一些新数据插入到已使用的磁盘空间（即DELETEs 不一定影响文件大小，但它们仍然在 PostgreSQL 自己的数据结构中释放空间）。这样对吗？（我注意到VACUUM FULL应用程序本身引起了一些问题，可能是因为它使用了锁。）

如果是这样，它似乎也SELECT pg_database_size('my_database')反映了磁盘上使用的大小，这不一定反映可用于进一步插入的内容。是否有另一种方法可以估算新插入物的可用空间？

此外，当为时已晚并且分区已填充到 100% 时，运行此DELETE语句会导致此错误并导致 PostgreSQL 服务崩溃：

恐慌：无法写入文件“pg_xlog/xlogtemp.7810”：设备上没有剩余空间

PostgreSQL 守护进程停止当然是一个主要问题（并且在这台机器上没有其他磁盘可以将集群移动到）。

是否有防止此类问题发生的通用策略（知道磁盘空间受限于给定分区内，但删除旧数据是可以接受的）？我想在没有rootor postgres（或 PostgreSQL 管理员）干预的情况下尽可能多地自动化。

CREATE TABLE data_group (
    id SERIAL PRIMARY KEY,
    name TEXT,
    input_datetime TIMESTAMPTZ
);

CREATE …

我有一个 tempdb 增长问题。让我通过提供我的 tempdb 设置来开始一切。

即使没有在数据库/服务器上运行查询，tempdb 的大小也会不断增加，开始迅速，然后缓慢而没有停止。我运行了许多查询来找出正在运行的内容，下面是查询的结果，它实际上给了我可以使用的结果。

可以看出，它们都是内部 spid 的，有什么方法可以找出 tempdb 继续失控的原因以及如何缓解它？对这个问题的任何帮助将不胜感激。

--Query that returned the result set
SELECT session_id,
       SUM(internal_objects_alloc_page_count)   AS task_internal_objects_alloc_page_count,
       SUM(internal_objects_dealloc_page_count) AS task_internal_objects_dealloc_page_count
FROM   sys.dm_db_task_space_usage
GROUP  BY session_id
HAVING SUM(internal_objects_alloc_page_count) > 0 

我一直在尝试在 MySQL 中创建一个“间隙和岛屿”识别例程。请参阅上一个有关此处设置和此处所需计算资源的问题。

我将数据库服务器的 RAM 增加到 4 Gb。查询运行正常，但现在我遇到了一个问题，即数据库服务器在运行查询时磁盘空间不足。

该查询查看整个数据库并将它找到的岛插入到名为 的表中shutdown_events。我使用INSERT IGNORE并查看整个数据库，这样我就不会切断跨越某种时间戳约束的岛屿（我尝试添加它，继续阅读......）。

我使用以下 SQL 创建了视图（dr.*_sd要包含~30 个值）

create view sd_pivot as
  select dr.wellsite_id, 'EngOilP_sd' as sd, dr.timestamp, dr.EngOilP_sd as val from datarecords dr
  union all
  select dr.wellsite_id, 'Stg1ScrbLVL_sd', dr.timestamp, dr.Stg1ScrbLVL_sd from datarecords dr
  union all
  select dr.wellsite_id, 'Stg2ScrbLVL_sd', dr.timestamp, dr.Stg2ScrbLVL_sd from datarecords dr
  union all
...

然后填充shutdownevents表的 SQL在这里：

INSERT IGNORE INTO shutdownevents (wellsite_id, sd_name, start, end)
SELECT t.* …

到目前为止，我尝试了多次索引重组查询。它们看起来像这样：

ALTER INDEX ALL ON TableName REORGANIZE

这样的查询可能需要几个小时，但它看起来不会干扰其他数据库操作。对于某些表，它的影响几乎为零，但对于某些表，它实际上节省了 15% 的整体数据库空间。

如果我每周左右对所有索引运行此查询会怎样？有什么理由不这样做吗？

我正在使用一个带有大型 TEXT 字段的 PostgreSQL 表，理论上该表会定期更新。我曾考虑过将数据直接存储在文件系统中，但使用 TOAST 时，数据已经存储在页外并压缩在数据库中，所以我想我会让事情变得简单，只使用数据库存储。

为了提供一些背景信息，我正在为 RSS 提要建立索引。我将每 24 小时运行一个脚本来提取 RSS 源并可能更新表格。这可能会导致大量死元组，从而占用大量磁盘空间。当然，autovacuum 最终会处理这个问题，但它可能会产生大量数据（很多 GB），我想确保我知道当我在这个非常大的表上进行大量更新时会发生什么。

我的一个解决方案是仅在提要发生某些重大更改（例如网站上出现新帖子）时才更新 TEXT 字段（存储 RSS 数据）。这意味着我可以避免进行更新，除非确实必须这样做。但是，我仍然想更新该表（以跟踪我最近执行 HTTP 请求的时间）。这将使用旧版本的行数据创建一个死元组。

如果 TEXT 数据实际上没有改变，会发生什么情况？当 UPDATE 创建死元组时，它还会复制 TEXT 数据吗？或者 TEXT 数据会保持不变，因为它没有更改并且存储在页外？