标签: vacuum

在我们的应用程序中,我们正在通过网络/电子邮件实现部分Core Data SQLite数据库的共享.为了保持文件小,我已经实现了以下方法来缩小Core Data数据库.

    - (void) shrinkDB
    {
        sqlite3 * database;
        NSString * string = [shareStoreURL path];
        const char * filename = [string cStringUsingEncoding:[NSString defaultCStringEncoding]];
        char *errMsg;
        if (sqlite3_open(filename, &database) == SQLITE_OK)
        {
            NSLog(@"Shrinking...");
            if (sqlite3_exec(database, "VACUUM;", NULL, NULL, &errMsg) != SQLITE_OK)
            {
                NSLog(@"Failed execute VACUUM");
            }
            sqlite3_close(database);
         }
        }

问题:上面的代码确实缩小了数据库.但Apple表示Core Data的实施细节随时都可能发生变化.你觉得在可预见的将来我会安全使用这种方法吗？或者还有其他更好的解决方案吗？

我最初认为n_dead_tup和dead_tuple_count在 PostgreSQL 中给出相同的计数。但他们似乎并非如此。我不太明白到底有什么区别。

以下是我的观察：

1. 创建了一个包含 10k 行的表。
2. 更新了所有 10k 行。现在我有 10k 个死元组。

SELECT dead_tuple_count FROM public.pgstattuple('public.vacuum_test');

 dead_tuple_count 
------------------
            10002

select * from pg_stat_get_dead_tuples('18466');

 pg_stat_get_dead_tuples 
-------------------------
                   10002

3. 我在桌子上吸满了真空。正如预期的 dead_tuple_count 为 0。

SELECT dead_tuple_count FROM public.pgstattuple('public.vacuum_test');

 dead_tuple_count 
------------------
                0

但从ien_dead_tup来看仍然是 10002：pg_stat_all_tablespg_stat_get_dead_tuples('18466')

select * from pg_stat_get_dead_tuples('18466');

 pg_stat_get_dead_tuples 
-------------------------
                   10002

我多次重复此过程，并观察到n_dead_tup每次更新后更新的元组数量都会添加到统计数据中。

那么VACUUM这里到底在做什么呢？n_dead_tup和和有什么区别dead_tuple_count？

我们在AWS RDS平台上运行PostgreSQL 9.3.每天凌晨1点我们都在做全球VACUUM ANALYZE工作.

昨天我们观察到性能严重下降,结果发现VACUUM ANALYZE过去5天我们有5个进程停滞不前.在相同的时间段内,磁盘利用率增加了45千兆字节.

我杀了它pg_terminate_backend但没有太大的影响.这些过程看起来已经死亡,但性能仍然严重下降.由于我们使用的是AWS RDS,我们已经执行了重启,故障转移和性能立即得到了显着改善.

今天早上我查了一下,发现VACUUM ANALYZE再次卡住了5个小时.我杀了它,但我怀疑它还在那里.

经过进一步调查,我确认auto_vacuum已正确启用,这意味着我们不需要运行手动,VACUUM但我们可能需要ANALYZE在部分或全部表上运行.

在我的研究中,我发现了这篇文章:http://rhaas.blogspot.com/2011/03/troubleshooting-stuck-vacuums.html和http://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT.

最后,我有以下问题:

1. 在没有启用auto_vacuum的情况下运行手动VACUUM是否正确？
2. 如何监控auto_vacuum的进度和性能？我怎么知道它与手册VACUUM没有卡在同一个地方？
3. 我还需要定期运行ANALYZE吗？
4. 有没有办法启用自动ANALYZE,类似于auto_vacuum？

我当前的尝试（根据此答案）如下所示：

@Service
class VacuumDatabaseService(
        private val entityManager: EntityManager
) {
    fun vacuumAllTables() {
        val session = entityManager.unwrap(org.hibernate.Session::class.java)
        val sessionImpl = session as org.hibernate.internal.SessionImpl
        val connection = sessionImpl.connection()
        connection.prepareStatement("VACUUM FULL").execute()
    }
}

但是它抛出：

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalStateException: No transactional EntityManager available

使用以下功能注释功能@Transactional：

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.reflect.UndeclaredThrowableException

Caused by: org.postgresql.util.PSQLException: ERROR: VACUUM cannot run inside a transaction block

可以使用以下方法，但是会感到危险的错误：

    @Transactional
    fun vacuumAllTables() {
        val session = entityManager.unwrap(org.hibernate.Session::class.java)
        val sessionImpl = …

我试图了解如何监控和调整 postgresql 性能。我从探索表开始pg_stat_all_tables，pg_stat_statements以便收集有关活元组、死元组、上次自动清理时间等的信息。有一些关于n_live_tuples（接近表中实际行数）和n_dead_tup我运行pg_stat_reset查询的有用信息。之后我得到了一些奇怪的结果 -n_live_tup少于n_dead_tup. 我找不到任何关于为什么以及何时（某些用例）应该运行pg_stat_reset查询的文章/文档。有人可以向我解释一下或提供一些有用的资源吗？

在sqlite中插入和删除大量记录后，sqlite db文件的大小不断增长，有没有办法使用django真空表？

• 一些让 sqlite 自动清空的设置
• 或手动编写自己的 django 命令到真空

更新：

我使用sqlite数据库浏览器执行以下SQL：

vacuum [my table];
commit;

效果很好，我只是想以编程方式进行

我有一个“小”问题。一周前，我的数据库已达到完整的磁盘容量。我删除了不同表中的许多行，以释放磁盘空间。至极后，我尝试运行完全真空至极并没有完成。

我想知道的是。当我停止完全压缩真空时，它是否在磁盘上留下了必须手动删除的任何临时文件？我现在有一个100％磁盘容量的数据库，不用说这是一个大问题。

有释放磁盘空间的提示吗？

我正在使用Postgres 8.1.4数据库运行SUSE。