首先说一下这个3节点MongoDB集群各个维度的数据规模： 1、dataSize: 1.9T 2、storageSize: 600G 3、全量备份-加压缩开关：186G，耗时 8h 4、全量备份-不加压缩开关：1.8T，耗时 4h27m 具体导出的语法比较简单，此处不再赘述，本文重点描述导入的优化过程，最后给出导入的最佳实践。 ■ 2023-09-13T20:00 第1次4并发导入测试 mongorestore --port=20000 -uadmin -p'passwd' --authenti…

MongoDB一个广为诟病的问题是，大量数据resotore时索引重建非常缓慢，实测5000万的集合如果有3个以上的索引需要恢复，几乎没法成功，而且resotore时如果选择创建索引也会存在索引不生效的问题，种种情况表明，MongoDB的一些默认设置存在明显不合理之处。 当然，深入理解后总会有办法解决这些问题，MongoDB发展到金，功能也是越来全面。 一、对于小数据量collection，可直接单命令行创建索引 类似如下操作： db.getCollection('processDataObj').createIn…

一个SQL查询很慢，查看执行计划出现了较多的“BITMAP CONVERSION FROM ROWIDS”，如下所示。 SQL_ID 1x9rd10ykjvjd, child number 0 ------------------------------------- select t.*, t.LIMIT_TIME - SYSDATE AS nowNumber, t.LIMIT_TIME - SYSDATE - i.manual_task_limit / 24 AS limitNumber from USER_W…

根据oracle对于SQL执行计划基于成本的优化原则，这么大的结果集，相对于400万的表来讲，索引不如全表扫描快。

晚间迁移数据库后，第二天下午来调优，发现CPU占用达到惊人的99%，如下： 分析15:00-16:00期间AWR报告，发现SQL硬解析严重，如下： 每秒硬解析达到69.9次，library hit%太低86%，如下： 此时的共享池达到了13G，如下： 可见有66次自动增大调整共享池的操作，由大量的SQL解析占用内存造成。 显然，这是因为应用没有合理使用绑定变量导致。 鉴于几年累积的大量应用难以短时间优化、修改SQL语句，因此决定修改数据库默认参数cursor_sharing，由EXACT修改为FORCE： alte…

以下展示了如何发现数据类型转换问题。