绿地数据库性能测试

我会做几件事:

1) 模拟用户/应用程序与数据库的连接,并测试负载(负载测试)。

2) 插入许多(可能是数百万)测试记录,然后再次进行负载测试。(可扩展性测试)。随着表的增长,您可能会发现您需要以前没有的索引。或者整个系统中使用的VIEWS或联接可能存在问题。

Here 这是一个描述它是什么的无聊页面。此外 here 是一篇关于Oracle数据库调优的精彩文章的链接。其中一些可能与你正在做的事情有关。

4) 运行应用程序/用户生成的查询,并为其运行解释计划。例如,这将告诉您何时进行全表扫描。这将帮助你解决很多问题。

5) 还要从这些备份中备份和重新加载,以显示对此的信心。

RedGate's Data Generator 在其中获取大量测试数据,以查看模式在负载下的性能。你说得对,在不了解使用模式的情况下,很难制定出一个完美的测试计划,但我认为你必须对将针对它运行的查询类型有一个大致的想法。

建模数据模式非常重要,因为大多数SQL执行计划都基于表“统计数据”,即计数和比率,现代RDBMS使用这些数据来计算最佳查询执行计划。有些人写过关于所谓的 "query optimizers" 例如。 Cost Based Oracle Fundamentals 由于缺乏内部工作原理的文档(通常是有意的,因为RDBMS供应商不想透露太多细节),解决其中一些问题往往是一个挑战。

回到你的问题,我建议采取以下步骤:

1. 给自己几天/几周/几个月的时间(取决于项目的规模和复杂性),尝试定义一个“成熟”(例如2-3年)数据库的状态,以及你需要在这个大型数据集上执行的一些性能测试用例。
2. 构建所有脚本以注入基线数据。您可以使用第三方工具,但我经常发现它们缺乏进行更高级数据分发的功能,而且编写SQL通常比学习新工具快得多。
4. 测试->tune->测试->调。..

创建一个单独的“数字”表,其中包含数百万行示例数据。该表可能包含随机字符串、GUID、数值等。 编写一个过程,将示例数据插入到您的模式中。使用数字列的模数(%)来模拟不同的UserID等。

创建一个“TestLog”表,您可以在其中记录测试查询的行数、开始时间和结束时间。

如果性能看起来很快,请考虑缓存未命中的可能性! 例如,如果您的生产服务器有32GB RAM,而您的表预计为128GB,则随机行查找>75%可能在缓冲区缓存中找不到。

为了模拟这种情况,您可以在运行查询之前清除缓存:

您可能会注意到性能下降了100倍,因为现在必须从磁盘加载索引和数据页。

使用标准技术来了解您的查询访问模式(扫描与查找)并调整性能。