我们有几个表,每个表都有近 1 亿行数据。一位同事将这些表设置为基于日期字段的分区。
我们的磁盘空间开始不足并且知道分区有自己的文件组,我想看看某些分区是否比它们需要的大并且正在咀嚼磁盘。
我运行了记录不佳的命令:
dbcc showfilestats
Run Code Online (Sandbox Code Playgroud)
这是输出的片段:
TotalExtents UsedExtents Name FileName
363200 200701 LogJun2013 F:\SQL\DATA\logs_phyJun2013.ndf
812800 432127 LogJul2013 F:\SQL\DATA\logs_phyJul2013.ndf
718400 401500 LogAug2013 F:\SQL\DATA\logs_phyAug2013.ndf
1016983 555565 LogSep2013 F:\SQL\DATA\logs_phySep2013.ndf
Run Code Online (Sandbox Code Playgroud)
如果我正确理解这一点(IANADBA),考虑到大量未使用的范围,这些文件中有很多未使用的空间。此外,我们只收集新数据,因此我们永远不需要从 2013 年开始扩大这些旧分区。
我对此的理解是否正确?如果是这样,我该如何从这些文件中释放空间?
我观察到生产环境中的 tempdb 在初始化后已经增长到 100 GB。
我知道由于服务器负载和一些昂贵的查询导致 tempdb 在短短两天内增长。我已经观察了一个多星期,发现这个尺寸没有进一步增长并且保持不变。
我在具有 8 个逻辑核心的服务器上为 tempdb 配置了一个 mdf 文件。虽然我可以根据逻辑核心添加多个 mdf 文件。
我观察到空闲页面大小和临时数据库数据文件的物理大小在我的情况下是相同的
SELECT SUM(unallocated_extent_page_count) AS [free pages],
(SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM sys.dm_db_file_space_usage;
Run Code Online (Sandbox Code Playgroud)
帮助我了解是否会在不显式执行脚本以缩小空间或通过重新启动服务器以重置临时数据库分配的情况下自动回收此物理空间?
我对 SQL Server 很陌生。我想收集整个 SQL Server 实例的数据库磁盘空间指标。
我找到了一个代码示例,可以收集每个数据库的磁盘空间信息。
IF OBJECT_ID('DISK.dbo.disk_activity') IS NOT NULL
DROP TABLE disk_activity
CREATE TABLE disk_activity (
servername NVARCHAR(100)
, database_id INT PRIMARY KEY
, name NVARCHAR(MAX)
, data_used_size DECIMAL(18,2)
, log_used_size DECIMAL(18,2)
)
DECLARE @SQL NVARCHAR(MAX)
SELECT @SQL = STUFF((
SELECT '
USE [' + d.name + ']
INSERT INTO DISK.dbo.disk_activity (servername, database_id, name, data_used_size, log_used_size)
SELECT
(SELECT @@SERVERNAME AS "Server Name") AS SERVER_NAME
, DB_ID()
, DB_NAME()
, SUM(CASE WHEN [type] = 0 …Run Code Online (Sandbox Code Playgroud) 我有一个 SQL Server 2008 R2 标准版数据库,我已为其配置了ROWS(.mdf) 数据库文件自动增长功能ON,并将最大大小设置为 10GB。
一段时间后,我收到一条警报,提示我的tempdb日志已填满驱动器。我认为我的数据库大小被限制在 9990MB 左右,无法进一步扩展。
这两件事可能有关联吗?无法扩展的数据库是否会将其事务存储在tempdb中?
当数据库ROWS文件已满并且有人不断向其中添加数据时会发生什么?
数据来自SQL Server性能数据监控:

假设我要在 SQL Server 中恢复备份(2 GB),我的磁盘中有足够的空间(20 GB),但是 SQL Server 是否遵循任何算法来计算所需的最小磁盘空间或只是随机检查磁盘空间和备份才能成功恢复。
因为我想了解SQL Server的内部工作原理。
提前致谢。
我正在使用 Azure SQL DB,并注意到我最大的数据库之一似乎有一个总大小为 6Gb 的主键索引。它是uniqueidentifier. 但是,在任何给定时间点,表中的总行数仅约为 78k 行。
该表存储出站电子邮件和短信,因此它会定期填满并清空。我们还对整个数据库进行每周索引维护,因此我试图理解为什么这个 PK 索引看起来远远大于其应有的值。
在某些情况下,HTML 电子邮件的大小几乎为 50KB。
根据我自己的本地测试,从该表中删除行似乎确实减少了 PK 的大小,但这似乎不会在生产数据库上发生。
然后我有什么选择来减少这个索引大小并释放我想象的大量未使用的空间。
如果我每天向同一个表的同一列中的同一行写入 4 个字节(整数)100,000 次,这会磨损 SSD 吗?对于 SSD 来说,每天 400 kb 不算什么,但将其写入同一个存储单元就会弹出它。
PostgreSQL 11我们在服务器下运行CentOS 7。最近,我们在日志中发现了几个导致 PostgreSQL 服务器崩溃的警告:
2022-05-09 23:26:29 EDT pg_restore db123 132.132.132.32 postgres ERROR: could not extend file "base/71592268/71621568": No space left on device
2022-05-09 23:26:29 EDT pg_restore db123 132.132.132.32 postgres HINT: Check free disk space.
(...)
2022-05-09 23:26:33 EDT DETAIL: Could not open file "pg_notify/0000": No space left on device.
2022-05-09 23:26:34 EDT LOG: database system is shut down
Run Code Online (Sandbox Code Playgroud)
目录下有几个数据库/var/lib/pgsql/11/data/base/:
# du -h /var/lib/pgsql/11/data/base/
7.7M /var/lib/pgsql/11/data/base/1
7.7M /var/lib/pgsql/11/data/base/13877
8.1M /var/lib/pgsql/11/data/base/13878
0 /var/lib/pgsql/11/data/base/pgsql_tmp
61M /var/lib/pgsql/11/data/base/852671
166M …Run Code Online (Sandbox Code Playgroud) 我有一个包含约 20 亿行数据的表,我想创建另一个包含一些聚合的表。看起来 PostgreSQL 使用临时磁盘空间来执行这些查询。我可以创建表...
CREATE TABLE my_new_table ...
Run Code Online (Sandbox Code Playgroud)
但是当我插入数据时:
INSERT INTO my_new_table SELECT
col_1,
col_2,
col_3,
col_4,
col_5,
col_6,
col_7,
col_8,
col_9,
sum(col_10),
sum(col_11)
FROM
my_table
GROUP BY
1,2,3,4,5,6,7,8,9
Run Code Online (Sandbox Code Playgroud)
PostgreSQL 似乎使用临时文件来存储结果,并且空间不足,例如出现如下错误:
无法写入文件“base/pgsql_tmp/pgsql_tmp31757.25”:设备上没有剩余空间
从 EXPLAIN 的结果来看,我怀疑这是来自某种排序。有办法避免这种情况吗?不会有那么多的输出行,所以不知何故,我觉得好像应该有一种方法可以在输出处做得更到位......但这是一个非常模糊的直觉。
如果我目前没有空间问题,我应该最初将我的 TempDB 大小设置为一个大空间而不是让它的空间被回收吗?
确定 TempDB 的最佳初始大小的最佳方法是什么?
我的 TempDB 目前为 12GB,并且设置为 10% 自动增长
disk-space ×10
sql-server ×6
postgresql ×3
tempdb ×2
aws-aurora ×1
backup ×1
crash ×1
group-by ×1
partitioning ×1
primary-key ×1
restore ×1