我有一个带有不可为空VARCHAR(MAX)列的表,其中每一行都包含一个空字符串(第三方数据库,因此我无法更改它)。我看到了大量的空间使用,超过 15GB 的 100 万行。
如果我运行以下查询,我会看到 LOB_DATA 的大量 used_pages,即使该列中没有数据。不包括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
Run Code Online (Sandbox Code Playgroud)
评论更新:
我们使用的是 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;
Run Code Online (Sandbox Code Playgroud)
我在这里没有发现任何问题。甚至我可以说上述命令的“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;
Run Code Online (Sandbox Code Playgroud)
我也曾经使用以下命令物理检查占用的数据库大小:
du -sh /usr/local/pgsql/data/base/2663326
Run Code Online (Sandbox Code Playgroud)
然后我从位置“ /usr/local/pgsql/data/base/2663326 ”开始按降序物理列出文件大小。这里,“2663326”是我的数据库的 OID。
[root@dbserver 2663326]# …Run Code Online (Sandbox Code Playgroud) 我有一个表,其中列中有很多 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;
Run Code Online (Sandbox Code Playgroud)
但是,在分区表上使用此命令存在一个已知错误。
在另一个问题中,我了解到我应该从我的一个表中优化布局以节省空间并获得更好的性能。我这样做了,但最终得到了比以前更大的表,并且性能没有改变。当然我做了一个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 | …Run Code Online (Sandbox Code Playgroud) 我想知道如何计算文件组中每个文件消耗的数据分布,回到存储它的索引(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 …Run Code Online (Sandbox Code Playgroud) performance monitoring sql-server dmv disk-space performance-tuning
我们有一个应用程序,我们每隔几秒接收一次信息,我们将这些信息记录在一个称为事件的表中,该表目前重达 240 GB,这是迄今为止我们拥有的最大的。
前段时间我们删除了记录以保留特定日期的记录。不久前我们发现存储数据库的服务器正在填满磁盘,删除数百万条记录后,磁盘空间保持不变。
在网上搜索我们发现执行以下查询 ALTER TABLE tablename ENGINE = Innodb; 将释放已删除记录的已用空间。
但是我们遇到的问题是,由于我们有大于200G的表,所以该命令执行时间较长,导致新信息因阻塞而无法及时插入。
我们找到的选项如下:
有没有更优化的方法来释放空间,而不必取消我们的服务并且不会丢失信息?或者如果必须在最短的时间内完成?
此查询 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 开发人员版。我也许可以更新,但出现的任何问题都将是我因偏离官方提供的版本而造成的。
disk-space ×10
sql-server ×5
mysql ×2
performance ×2
postgresql ×2
datafile ×1
datatypes ×1
dmv ×1
innodb ×1
mariadb ×1
monitoring ×1
null ×1
partitioning ×1
shrink ×1
ssms ×1
ubuntu ×1
vacuum ×1