标签: database-size

我们正在为生产使用准备一个 PostgreSQL 数据库，我们需要估计这个数据库的存储大小。我们是一个在数据库管理方面缺乏专业知识的开发人员团队，因此我们正在研究、阅读手册并使用我们的一般信息技术知识来实现​​这一目标。

我们有实际数据要迁移到这个数据库，并对增长有一些粗略的估计。为了这个例子，假设我们估计每年增长 50%。

关键是：进行良好尺寸估计的一般正确技术是什么？

我们根据以下规则估算存储使用量。我们需要建议的主题用粗体文本标记。非常欢迎对整个过程的反馈：

1. 估计每个表的大小
   1. 发现每一行的实际大小。
      • 对于具有固定大小的字段（如bigint、char等），我们使用文档中描述的大小
      • 对于具有动态大小的字段（如text），我们估计了字符串长度并使用了函数select pg_column_size('expected text here'::text)
      • 我们为PostgreSQL 内部使用的OID增加了 4 个字节
   2. 将每行的大小乘以估计的行数
   3. 我是否需要在这里考虑任何开销，例如行或表元数据？
2. 估计每个表索引的大小
   • 不知道如何估计，这里需要建议
3. 估计事务日志的大小
   • 不知道如何估计，这里需要建议
4. 估计备份的大小（完整和增量）
   • 不知道如何估计，这里需要建议

5. 对实际最小尺寸的所有估计求和

6. 对 1 年后的最小规模的估计值 1、2 和 4 的总和应用 1.5 倍（增长 50%）的系数

7. 应用 1.2 ~ 1.4（多 20% 到 40%）的总体系数来估计 5 和 6 以获得良好的安全裕度

我知道规则变得相当广泛。让我知道是否需要示例以更好地理解。

这个问题被问了几十次，令我惊讶的是，这样一个简单的要求变得如此困难。然而我无法解决这个问题。

我使用 SQL Server 2014 Express 版，数据库大小限制为 10GB（不是文件组大小，数据库大小）。

我抓取了新闻，并将 HTML 插入到表格中。表的架构是：

Id bigint identity(1, 1) primary key,
Url varchar(250) not null,
OriginalHtml nvarchar(max),
...

数据库容量不足，我收到了 insufficient disk space

当然缩小数据库和文件组没有帮助。DBCC SHRINKDATABASE没有帮助。所以我写了一个简单的应用程序来读取每条记录，去掉一些不需要的部分，OriginalHtml比如 head section 和 aside 和 footer 以只保留主体，现在我在获取顶级表的磁盘使用情况报告时看到这个图像：

据我了解这张图片，未使用的空间现在占总大小的 50%。也就是说，现在我有 5GB 未使用的空间。但我无法收回它。重建索引没有帮助。该truncateonly选项无济于事，因为据我所知，没有记录被删除，只有每条记录的大小减少。

我被困在这一点上。请帮忙，我该怎么办？

聚集索引在列上Id。

这是结果 EXECUTE sys.sp_spaceused @objname = N'dbo.Articles', @updateusage = 'true';

name        rows     reserved     data        index_size   unused
----------- -------- ------------ ----------- ------------ -----------
Articles    112258   8079784 KB   5199840 KB  13360 KB …

我有一个 Vertica 数据库。我怎么知道数据库有多大？

我需要一个粗略的答案，以便向高层管理人员报告有关我们环境的基本统计数据。

我偶然发现了一个关于 SO的算法/数据结构问题，我将简短引用：

(...) 关于用于索引时间序列的最佳数据结构的意见（又名列数据，又名扁平线性）。

需要的查询：

All values in the time range [t0,t1]

All values in the time range [t0,t1] that are greater/less than v0

All values in the time range [t0,t1] that are in the value range[v0,v1]

Run Code Online (Sandbox Code Playgroud)

数据集由汇总的时间序列组成 (...) 所讨论的数据集大小约为 15-20TB，因此以分布式方式进行处理 - 因为上述某些查询将产生数据集大于任何一个系统上可用的物理内存量。

在这种情况下，分布式处理还意味着将所需的数据特定计算与时间序列查询一起分派，以便计算可以尽可能靠近数据发生 - 从而减少节点到节点的通信（有点类似于 map/减少范式）-简而言之，计算和数据的接近度非常关键。

我很容易承认这种规模的问题超出了我的头脑，但是我的第一个预感（即使提到了数据大小）考虑到这个问题，我会问他们是否检查了大型 RDBMS（好吧，我猜是 Oracle ，或 Oracle，对吗？）可以以理智的方式处理这个问题。

所以这里的问题是：今天，（企业？）RDBMS 能否以可接受的性能与“手工编码”解决方案处理此类问题。

注意：希望这不是太模糊，并随时根据需要重新标记:-)

我在同一个 MySQL 服务器上运行了数百个数据库。如何获得按数据库大小排序的列表？

我使用以下脚本从我的数据库中收集数据，即 Azure 上的 SQL Server。

-- Script to run against database to gather metrics

CREATE TABLE #SpaceUsed (name sysname,rows bigint,reserved sysname,data sysname,index_size sysname,unused sysname)

DECLARE @Counter int 
DECLARE @Max int 
DECLARE @Table sysname

SELECT  name, IDENTITY(int,1,1) ROWID 
INTO       #TableCollection 
FROM    sysobjects 
WHERE xtype = 'U' 
ORDER BY lower(name)

SET @Counter = 1 
SET @Max = (SELECT Max(ROWID) FROM #TableCollection)

WHILE (@Counter <= @Max) 
    BEGIN 
        SET @Table = (SELECT name FROM #TableCollection WHERE ROWID = @Counter) 
        INSERT INTO #SpaceUsed 
        EXECUTE sp_spaceused …

我不明白为什么我们的 AWS postgres 服务器耗尽了它的所有空间。我们只需要增加分配给它的存储空间，但无法从 postgres 中找到任何关于它正在使用那么多空间的提示。

亚马逊表示，我们在过去两周内吃掉了大约 60GB。Postgres 说我们的整个数据库仅超过 5GB，数据库操作主要是 INSERT 和 SELECT。

如何追踪和回收我们的存储？

这是 PSQL 中一些 size 命令的输出

select pg_size_pretty(pg_database_size('my_db'));
-- 3730 MB

SELECT     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', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
  ORDER BY pg_total_relation_size(C.oid) DESC
  LIMIT 20;

给

1540 MB
1286 MB
235 MB
191 MB

奇怪的是 autovacuumer 从未在任何表上触发（我假设这是因为我们很少删除行？）相对于表大小，死行的数量相当低（这些表的行数为数十万或百万）

SELECT
  vacuum_count, autovacuum_count, n_dead_tup
FROM pg_stat_user_tables ORDER BY n_dead_tup …

我有一个大型 SQL Azure 数据库（P6 大小接近 1TB）。我想清理/删除任何未使用的索引。在过去的 30 天里，我们捕获了以下 2 组信息。

参见：https : //gist.github.com/eoincampbell/3fe775d43e86ad342f9c6eba10f350f9

• 从sys.dm_db_index_physical_statsjoin 到收集的索引统计数据sys.tables，sys.schemas以及sys.indexes
• 索引使用收集自 sys.dm_db_index_usage_stats

我对sys.dm_db_index_usage_stats. 从文档中不清楚何时/是否在 SQL Azure 环境中发生以下情况（与单实例 MSSQLServer 相比）。

https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-index-usage-stats-transact-sql?view=azuresqldb-current的每当 SQL Server (MSSQLSERVER) 服务启动时，计数器都会初始化为空。此外，无论何时分离或关闭数据库（例如，因为 AUTO_CLOSE 设置为 ON），与该数据库关联的所有行都将被删除。

这是我用于随后识别未使用索引的查询。它

1. 获取数据库中所有索引的最新索引信息（812条记录）
2. 获取所有索引的最新使用信息（558条记录）
3. LEFT OUTER 将它们连接在一起
4. 排除任何聚集/PK 索引
5. 返回任何没有使用统计信息或任何用户读取统计信息为零的内容。

返回的总行数约为 219 行

这种方法看起来有效吗？

询问

WITH MostRecentStats (
    SchemaName, TableName, IndexName, IndexType, AllocUnitType, Pages, MostRecentAt
)
AS (
    SELECT      SchemaName, TableName, IndexName
                , IndexTypeDescription, AllocUnitTypeDescription
                , Max(PageCount) , …

我有一个非常大的表，带有 blob 字段，称为data. 我试图弄清楚为什么它没有被很好地缓存并且重复的SELECTs 很慢：

=> SELECT pg_size_pretty(pg_total_relation_size('data'));
157 GB

这看起来有点大，所以我试着总结一下数据：

=> SELECT pg_size_pretty(pg_relation_size('data'));
19 GB

随着指数：

SELECT pg_size_pretty(pg_relation_size('data_pkey'));
757 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB
SELECT pg_size_pretty(pg_relation_size('data_merged_idx'));
854 MB
SELECT pg_size_pretty(pg_relation_size('data_owner_idx'));
794 MB
SELECT pg_size_pretty(pg_relation_size('data_session_format_idx'));
779 MB

数据和索引大小的总和约为 26 GB，但总关系大小接近 160 GB。该表刚刚从转储中恢复，此后没有进行任何写入。

• 这种差异的解释是什么？
• 有什么办法可以减少浪费的磁盘空间？聚类会有帮助吗？

我们使用的是 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]# …