加快依赖 Oracle DB 的集成测试
我们有一个专门用于运行单元测试的 Oracle 数据库服务器。有没有办法专门针对这种目的调整 Oracle？由于数据不断被丢弃（因为它只是测试数据）。我想知道是否有一种方法可以让 Oracle 数据库位于内存中并在没有 TCP/IP 堆栈的情况下进行连接，也许可以加快这些测试的速度。
有什么建议吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
答案可能是肯定的，但是在测试期间将数据库环境从生产配置更改为集成配置会带来测试给出错误结果的风险。
The answer is likely yes, but changing the database environment from the production configuration to a integration configuration during testing introduces risk that the testing will give false results.
如果挂起是数据库清理/重置阶段，并且您使用的是企业版，请查看 闪回数据库（可能）是一种将数据库重置到固定点的更快方法。
最坏的情况是，您不需要浪费时间构建清理/重置脚本。
If the hangup is the database cleanup/reset stage, and you have Enterprise Edition, look into FLASHBACK DATABASE as (potentially) a quicker way to reset the database to a fixed point.
At worst, you don't need to waste time building the cleanup/reset scripts.
TCP/IP 堆栈不太可能增加太多开销。但是，您可以在与测试用例相同的服务器上运行 Oracle 实例，并通过 ORACLE_SID 进行访问（我相信它使用操作系统级进程间通信）。
不过，在检查 Oracle 的更改之前，我会先了解一下持续集成服务器上正在运行哪些测试。如果您还没有这样做，这意味着将集成测试（需要后端）与单元测试（不需要后端）分开，并按不同的计划运行它们。很少有理由为每个更改运行全套集成测试。
下一步：您是否使用任何类型的对象关系映射器来访问数据库？如果是，并且您不依赖于任何特定的 Oracle 怪癖，您可以将 Oracle 替换为内存数据库（您没有说明您正在使用什么语言，因此这可能是也可能不是一个选项）。
最后，考虑使用 Oracle 导入/导出工具为每次集成测试运行完全重建数据库。它可能比尝试删除您创建的任何行更快，而且肯定更稳定（这假设您的集成测试从预先填充的数据开始；如果不是，只需删除并重建架构）。
The TCP/IP stack is unlikely to be adding much to your overhead. You could, however, run the Oracle instance on the same server as your test cases, and access via ORACLE_SID (which I believe uses OS-level inter-process communication).
Before examining changes to Oracle, however, I'd look at what tests are getting run on your continuous integration server. If you haven't done it already, this means splitting the integration tests (which require a back end) from the unit tests (which don't), and running them on different schedules. There's rarely a reason to run a full suite of integration tests for every change.
Next: are you using any sort of object-relational mapper to access your database? If yes, and you're not relying on any particular Oracle quirks, you could replace Oracle with an in-memory database (you don't say what language you're using, so this may or may not be an option).
And finally, consider using the Oracle import/export facility to completely rebuild your database for each integration test run. It's probably quicker, and definitely more stable than trying to delete whatever rows you created (this assumes that your integration tests start with pre-populated data; if not, just drop and rebuild the schema).
对于您提到的场景，您可以对 Oracle 实例执行很多操作，例如使用正确的锁定策略/隔离级别、禁用各种撤消日志等。您应该为此查阅一本好的 Oracle 调优书籍（我就像马克·高锐（Mark Gurry）的那个，但我不确定它是如何更新的）。
还有一件事可能很重要：如果您不断从数据库中添加和删除数据（我的意思是“完全清空数据库”），请确保正确设置每个表的存储参数。如果您有空间，请考虑为测试用例分配等于最大大小的初始范围。 （在数据库创建脚本中，或者定义一次，然后使用重用存储选项来转换表。）然后，当您运行测试用例时，数据库不必分配额外的存储空间。
There are a lot of things you could do to the Oracle instance for the scenario you mention like using the correct locking strategy/isolation level, disabling all kinds of undo-logs, etc. You should consult a good Oracle Tuning book for that (I like the one by Mark Gurry, but I'm not sure how up to date that is).
There is one other thing that might be important: If you constantly add and delete data from your db (I mean "totally empty the db"), make sure you're setting up the storage parameter for each table correctly. If you have the space, consider assigning an initial extent equal to the max size for your test cases. (Either in the db creation script, or define once and then just trancate the tables with the reuse storage option.) Then when you run the test cases, the db doesn't have to allocate additional storage space.
我遇到了类似的问题，通过将重做日志、撤消和用户表空间移动到 RAM 磁盘，我能够加快单元测试的速度。有一个 商业版本也非常便宜。
就我而言，单元测试仅验证数据完整性，因此该策略风险较低，即使它不复制生产设置。我们有单独的规模和性能测试策略。
I faced a similar issue and I was able to speed up the unit tests by moving the redo logs, undo and users tablespace to a RAM disk. There is a free version of ramdisk software available for you to try out. Commercial versions that back up the files periodically are also very cheap.
In my case the unit tests only verify data integrity and hence this strategy is low risk even though it is does not replicate production setup. We have a separate scale and performance test stgrategy.
您可以将表索引的重建作为测试运行的一部分。选择在运行之前或运行之后重建索引的时间。您将消耗相同的总时间，但如果您在试运行后重建它们，您会“感觉”得更少。
将重建索引而不删除并重新创建它们。
You can incorporate rebuilding of your table indexes as part of the test run. Choose to either take the time hit of rebuilding your indexes prior to the run or after the run. You'll eat up the same total amount of time, but you'll "feel" it less if you rebuild them after the test run.
Will rebuild the indexes without dropping and re-creating them.