心得和总结

 

一下内容是阅读一些文档时看到的。

 

在Oracle 社区中，关于如何对系统调优以得到最佳的性能（或者如何最佳地使用各种Oracle 特性）

有许多“常识“。这种原本明智的”常识“有时却演变成为一种”传说“甚至”神话“，这是因为开发人

员和数据库管理员可能不加如何批判地采纳这些思想，或者不做如何思考就盲目扩展它们。

 

 

 

一些最佳实践取决于（或部分取决于）事实的真实性，有时，随着事实的改变，这些最佳实践可能

不再适用。请考虑一句古老的格言：“要得到最好的性能，应当把索引和数据放在单独的表空间中。“我

经常发现许多数据库管理员都恪守着这个观点，根本不考虑如今磁盘的速度和容量已经大为改观，也不考

虑给定工作负载的特殊要求。要评价这个”规则“是否合适，应该考虑这样一个事实：Oracle 数据库会

在内存中缓存最近经常使用的数据库块（通常这些块属于某个索引）。还有一点需要考虑：对于给定的请

求，Oracle 数据库会顺序使用索引和数据块，而不是同时访问。这说明，所有并发用户实际上应该都会执

行涉及索引好数据的I/O 操作，而且每块磁盘上都会程序I/O 操作。可能你会出于管理方面的原因（或者

根据你的个人喜好）将索引和数据块分置于不同的表空间中，但就不能说这样做是为了提高性能。（Thomas

Kyte 在Ask Tom 网站http://asktom.oracle.com 上对这个主题做了深入的分析，有关文章可以在”index

13/849 data table space“中查到。）从中我们可以得到一个教训，要根据事实做出决定，而且事实必须是当前

的、完备的。

 

 

 

 不要相信神话，要自己思考。

 不要墨守成规，所有人都知道的事情其实很可能是错的！

 不要相信传言，要自己测试，根据经过证明的示例做出决定。

 将问题分解为更简单的小问题，再把每一步的答案组合为一个优秀、高效的解决方案。

 如果数据库能更好、更快地完成工作，就不要事必躬亲地自己编写程序来完成。

 理解理想和现实之间的差距。

 对于公司制定的未加证实的技术标准，要敢于提出质疑。

 要针对当前需求从大局考虑怎样做最好。

 要花时间充分地思考。

 

 

 写道

并发问题最难跟踪，就像调试多线程程序一样。在调试工具控制的人工环境下，程序可能工作得很好，
但到实际中却可怕地崩溃了。例如，在竞争条件下，你会发现两个线程力图同时修改同一个数据结构。这
种bug 跟踪起来非常困难，也很难修正。如果你只是独立地测试你的应用，然后部署，并交给数十个并发
用户使用，就很有可能痛苦地遭遇原先未能检测到的并发问题。

 以前不知道到底怎么就会出问题，知道自己实践中出现这种情况才明白，哎，深有体会啊！呵呵

 

 

来自oracle资料 写道

写入器（writer）不会阻塞读取器（reader）。换种说法：读（read）不会被写（write）阻
塞。这一点几乎与其他所有数据库都不一样。在其他数据库中，读往往会被写阻塞。尽管听上
去这个特性似乎很不错（一般情况下确实如此），但是，如果你没有充分理解这个思想，而且想
通过应用逻辑对应用施加完整性约束，就极有可能做得不对。