元芳曰：这种情况基本都成为了DBA的家常便饭，经常要去处理用户提交来的性能问题或者是工程人员提交上来的AWR报告，一般遇到这种情况，解决的方法有很多。
OLTP
（1）先要弄清楚数据库的类型是什么 OLTP 在线事务处理 or OLAP 在线分析系统，因为不同的数据库类型选择优化的方法也不同。例如 OLTP 强调系统的内存命中率，内存的效率决定数据库效率。
（2）如果用户的并发数很大可扩大内存的容量缓存更多的数据，还可以调整data buffer cache、shared pool、java pool、large pool的大小及PGA大小包括sort区hash区等。
（3）如果用户的在线请求数较多，可以尝试着进行SQL的变量绑定，缓解SQL的硬解析，当遇到成千上万的查询操作时，能够不经过解析过程直接使用缓存的执行计划，那效率可以提高n倍。因为硬解析会做2个分析。第一 语法分析：检查代码的语法是否正确。第二 语义分析：检查代码执行的对象是否存在及对执行对象的权限是否有。解析过程十分的耗费CPU资源。
（4）数据块的争用，是因为数据分配的不均匀造成的，可以使用hash算法平均打散到各个磁盘上来减少热块的产生
（5）还有很多系统性能间接的反应为数据库性能，例如 网络的延迟 主机的应用程序较多 没有采用中间件策略构建预处理缓冲池
OLAP
（6）如果是OLAP 在线分析系统的话，当一个用户找你来说查询一张报表很慢，你可以通过用户会话来找到查询的SQL语句，检查这条语句逻辑上效率如何，可以使用Hint方式来改变sql的执行计划，检查数据的访问方式，是走全表扫描还是走索引效率最高，调整SQL的执行计划，选择合适的索引
（7）因为SQL大多数就是集合的数学运算操作，SQL表的关联方式是不是最优化，哪种join最适合，这都是要考虑的范围
（8）当你手工测试完后，对表进行统计分析，看看优化器和你选的执行计划是不是相同的
（9）CBO模式的选择，对于需要快速响应用户的请求，可以设置成first_rows(优先把部分数据返回)，对于用户响应不是很严格的业务，可以设置成all_rows（所有处理数据一次性返回）
（10）如果系统的整体开销不大，可以考虑并行技术
（11）对于OLAP系统最直接的提高数据库性能方法增加磁盘I/O和CPU吞吐量，如果硬件搞不了，可以采用数据库压缩技术，减少空间提高I/O
（12）随着数据量的增加，以前不是问题的问题也变成了问题，对于OLAP系统SQL的效率决定数据库效率