我有一个非常大的表，带有 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]# …

我发现我的数据库，特别是USERS表空间的大小急剧增加。

我如何才能找到对位于此表空间中的对象执行的 DML 操作？

问题：

我的 Java 应用程序ORA-01691: unable to extend lob segment每次插入都返回错误

原因：

运行后：

SELECT * 
FROM dba_tablespace_usage_metrics 
ORDER BY used_percent desc;

我发现SYSTEM数据文件已满 99.81%（并且由于某种原因只有 4MB）。

解决方案尝试：

1. 我打开了自动扩展

   ALTER DATABASE 
   DATAFILE '/home/user/oracle/orcl/system01.dbf' 
   AUTOEXTEND ON NEXT 2048M 
   MAXSIZE UNLIMITED;
   

   Run Code Online (Sandbox Code Playgroud)

   ...执行得很好，但没有增加大小。

2. 然后我尝试手动增加大小：

   ALTER DATABASE 
   DATAFILE '/home/user/oracle/orcl/system01.dbf' 
   RESIZE 2048M;
   

   Run Code Online (Sandbox Code Playgroud)

...这给出了一个错误，即我尝试使用的新大小最终会截断数据。这当然没有意义，因为当前大小是 4MB。我还尝试将 2GB 粘贴为字节而不是“2048M”，因为我认为它可能无法理解“2048M”。虽然这给出了同样的错误。

摆脱ORA-01691: unable to extend lob segment错误的实际工作方式是什么？

当我在 MY_Database 上运行以下查询时

select * from sys.sysfiles

我得到以下结果：

但是当我运行一个动态查询来获取可用空间的百分比时，我得到：

消息 8115，级别 16，状态 7，第 93 行 将数字转换为数据类型数字的算术溢出错误。

DECLARE @command NVARCHAR(MAX) 
SELECT @command = 'SELECT  db_name() as db_name,
CAST(S.size/128.0 - CAST(FILEPROPERTY(S.name, ' + '''' +  
               'SpaceUsed' + '''' + ' ) AS int)/128.0 AS int) AS FreeSpaceMB  
        ,CAST(100 * (CAST (((S.size/128.0 -CAST(FILEPROPERTY(S.name,  
        ' + '''' + 'SpaceUsed' + '''' + ' ) AS int)/128.0)/(S.size/128.0))  
        AS decimal(5,2))) AS varchar(8)) + ' + '''' +  '''' + ' AS FreeSpacePct
        FROM sys.sysfiles S'  

exec …

关于查询数据库文件大小...

1) 大多数（如果不是全部）这些答案并不总是与文件资源管理器中显示的物理文件大小匹配：

/sf/ask/416175231/

该接受的答案报告：      

对比

2）这篇文章似乎与文件资源管理器中显示的物理文件大小相符：

是否有一个查询可以在不依赖 dm_os_performance_counters 的情况下报告物理大小？第一组查询是否忽略了可用空间？

文件资源管理器报告的实际大小：

为什么 Tempdb 显示的数据和日志文件大小都存在差异，如图所示？

Microsoft SQL Server 2012 (SP3) (KB3072779) - 11.0.6020.0 (X64)

当您使用诸如sys.database_files之类的东西时，它以 8 KB 页面为单位给出文件的大小，而与它进行比较的许多其他内容以 MB 为单位。

有多种方法可以将 8 KB 页面转换为 MB，查询的答案中提供了几种方法来报告磁盘空间分配和已用空间

最常见的两种是

• 乘以 8 并除以 1024 (128000 * 8 / 1024 = 100)
• 除以 128 (128000 / 128 = 100)

第二种更简单，只需要一个操作。但两者似乎都给出了相同的答案。

选择一种方法而不是另一种方法有充分的理由吗？

我正在学习动态树结构组织以及如何设计数据库。

考虑具有以下特征的 DBMS：

• 大小为 2048 字节的文件页
• 12 字节的指针
• 56 字节的页头

二级索引定义在 8 字节的页面上。可以用三级 B 树索引的最大记录数是多少？并且具有三级 B+树？

以下是这些树的两个示例：

我的尝试

B+树

我读过那个

B+树比B树浅。因为除了最后一个之外，每个叶节点中只有表示为k的最高键的集合存储在非叶节点中，组织为 B 树。关系 DBMS 内部，第 5 章：动态树结构组织，第 46 页