标签: disk-space

SQLite 常见问题说明如下：

(12) 我删除了很多数据，但数据库文件并没有变小。这是一个错误吗？

不会。当您从 SQLite 数据库中删除信息时，未使用的磁盘空间会添加到内部“空闲列表”中，并在您下次插入数据时重新使用。磁盘空间不会丢失。但它也不会返回到操作系统。

您能否向我解释该决定背后的动机（与立即将可用空间返回给操作系统相反）？这种决定（包括不明显的）的利弊是什么？

这个说法正确吗？

在幕后 SQL Server 实际上将视图中的数据存储为物理表，如果视图背后的任何数据发生更改，则必须更新该物理表

我做了一些搜索，但找不到任何关于视图如何在 SQL Server 中工作的资源。我一直认为除非您使用索引/物化视图，否则视图不会占用任何额外的数据空间。

谢谢

我的数据库还有 16MB 的空间。

我曾经只是按照我的教导进行截断，但我发现这些链接建议不要截断：

http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

除了删除表记录之外，我还能在我的数据库上做些什么来减小大小吗？我是 DBA 论坛的新手，我可能应该在发帖之前四处寻找其他问题，但我很绝望，因为我担心我的数据库会崩溃。

我希望这个问题对某人来说很容易回答:)

我有一个看起来像这样的表（隐藏了不重要的列）

CREATE TABLE [dbo].[Log](
    [LogID] [int] IDENTITY(1,1) NOT NULL,
    --several other columns
    [Name] [nvarchar](512) NOT NULL,
 CONSTRAINT [PK_Log] PRIMARY KEY CLUSTERED 
(
    [LogID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

现在我对该表做了一些索引，这也涉及将Name-column缩短到 256 宽度。但是当我更改此列时

ALTER TABLE Log ALTER COLUMN Name NVARCHAR(256) NOT NULL
GO

数据库增长了一个不平凡的数量。（是的，我仔细检查了 - 这是我在这里所做的唯一更改）该表总共有 90746 个条目，在更改表之前，SSMS 表示大小为 247.56MB。

但是在这次更新之后，数据库增长到了 336.13MB。

不知道这在这里是否重要，但SELECT @@VERSION得到Microsoft SQL Server …

我在 Ubuntu 14.04 上使用 Postgres 9.5。我想在日志达到特定大小时旋转它们。所以我编辑了 /etc/postgresql/9.5/main/postgresql.conf 并设置了这个

log_rotation_size = 50MB                # Automatic rotation of logfiles will
                                        # happen after that much log output.
                                        # 0 disables.

然后我重新启动了我的服务器

sudo /etc/init.d/postgresql restart

但是在运行了一些操作之后，我的磁盘空间用完了，并且发现我的日志根本没有轮换……

myuser@mymachine:~$ ls -al /var/log/postgresql/postgresql-9.5-main.log
-rw-r----- 1 postgres postgres 3165773943 Dec 29 18:34 /var/log/postgresql/postgresql-9.5-main.log

我还需要做什么才能开始日志轮换？

我在 Ubuntu 14.04 上使用 Postgres 9.5.4。我的 Postgres 数据位于单独的磁盘分区上，该分区已满。

myuser@myproject:~$ df -h /mnt/volume-nyc1-01/
Filesystem Size Used Avail Use% Mounted on
/dev/sda 99G 93G 413M 100% /mnt/volume-nyc1-01

我想从分区中删除一些数据，但这变得很有挑战性。特别是，当我运行一些查询时，我得到这样的结果

myproject_production=> select count(*) FROM my_object_times rt1, my_object_times rt2 where rt1.my_object_id = rt2.my_object_id and rt1.name = rt2.name and rt1.time_in_ms = rt2.time_in_ms and rt1.id > rt2.id;;
ERROR:  could not write block 52782 of temporary file: No space left on device

我想释放一些临时空间，以便我可以运行查询并确定需要删除哪些数据。我的另一个分区上还有一些其他可用空间。如何将 pgsql_tmp 变量指向那里，以便我可以运行我需要的查询？

编辑：

由于符号链接选项似乎是侵入性最小的，所以我尝试了一下，设置如下

myuser@myproject:~$ sudo ls -al /mnt/volume-nyc1-01/postgresql/9.5/main/base/pgsql_tmp
lrwxrwxrwx 1 root root 14 Apr …

我最近为 RDS 数据库调整了数据和日志文件的大小，只留下了几 GB 的未分配空间。此后不久，分配了一些内容，然后又释放了 1 GB 的误差幅度。这可能是什么原因造成的？

所有数据库 - 包括 tempdb - 要么很小（MB），要么正好是它们设置的大小；它们加起来为 197 GB，在 200 GB 实例上留下 3 GB 可用空间。但是：

显然，如果这种情况再次发生，幅度稍大，就会出现问题。现在，我可以简单地缩小一个数据库文件以提供更大的余量，但我想了解实际发生了什么。

我只是想知道：

1. SQL Server 如何在删除 1GB 表后重用保留空间？（调用表T1）
2. SQL Server 如何在截断表后重用保留空间？（称此表为 T2）

两者都是聚簇表（不是堆）。

在大型表上运行 VACUUM FULL之前，是否可以检查表空间中有多少可用的可重用空间？

我有一个很大的 postgres 表（大约 20G），偶尔会出现 VACUUM FULL 的情况。该驱动器上的可用空间在 15-25 GB 之间变化。在尝试每次真空之前，我都会记录表大小（使用 postgres 查询）和可用磁盘空间（使用操作系统工具）。

我知道 VACUUM FULL 需要对表进行完整复制。因此，如果表为 20G，则需要 20G 的可用空间。

有时表有 20G，只有 15G 操作系统空间可用，真空将起作用。我猜所需的额外 5G 是从表空间内部恢复的。

其他时候，vacuum 会由于空间不足而失败，我猜在这些情况下，表空间中找不到所需的额外 5G。

我希望能够事先检查是否有足够的空间用于 VACUUM FULL，我该怎么做？我知道表有多大，我知道操作系统有多少可用空间，但我不知道表空间中有多少可重复利用的空间。

我们有一个大型查询，当客户“第一次运行它时，一大早......”

所以，我发现pg_prewarm我想使用加载到 PG 的缓冲区缓存一定数量或最近访问的行（插入、更新或删除）来自上述查询中使用的几个表。

此外，我需要确保“预热”不超过 PG 的缓存（我相信是 shared_buffers 设置，还是我错了？）为了预热单个表的最后 1000 页，我可以这样做：

SELECT pg_prewarm(
    'mytable',
    -- "pre warm" last 1000 pages
    first_block := ( 
        SELECT pg_relation_size('mytable') / current_setting('block_size')::int4 - 1000
    )
);

问题 1：这种方法有意义吗？

诀窍是 pg_prewarm 只能加载一定数量的页面，所以我需要计算“某个表的页面中有多少活动行”

-- show some settings
SELECT current_setting('block_size')::int4 AS page_size_bytes; -- 8192
SHOW shared_buffers; -- 512 MB


-- https://www.postgresql.org/docs/current/static/pgstattuple.html
--CREATE EXTENSION pgstattuple;
-- find out live row size and live rows per page
SELECT 'mytable'AS table_name, pg_size_pretty(tuple_len / tuple_count) AS live_row_size, 8192.00 / (tuple_len …