方法有：1、调大临时表空间所对应的bufferpool2、临时表空间存储使用SSD，DB2临时表空间的写操作基本都是随机IO，SSD随机IO强，可以大幅提升关联、聚合、排序等大量消耗临时表空间的查询性能...

先在测试环境跑，验证没问题了再上生产。建表空间和用户及用户权限的脚本语句就没什么可优化的了。

操作系统层面也有很多工具，例如ibm提供的nmon，例如oracle提供的osw，他们都有unix和Linux版本。这些工具都可以按照自定义的频率和时间段来对操作系统各个层面（cpu、内存、io、网络等多方面）进行监控并输出日志。通过日志我们可以对特定问题进行诊断和优化。...

首先，针对一般性的OLTP系统，应该有一个ORACLE官方的最佳实践。我们应该根据这个最佳实践把相应的内存参数、网络参数、IO参数等进行核对。文档 ID 1526555.1文档 ID 1525820.1具体可以查阅oracle官方support网站。当然这个里面记录的内容仅仅是一些基本的最佳实践，并不包括...

reorg的目的是什么？是不是可以考虑用ADMIN_MOVE_TABLE对表执行在线的转移呢？当然这个虽然是在线的，在最后的转换完成之前也会出现一段时间的锁表状态，需要测试评估。另外一个方案是考虑用CDC等复制工具复制一张表出来，追平后手动切换，经历的时间会比较长，但切换时间可以做到秒级...

这个一个产品选型的数据库的简易版本，真实的数据库比这里的数据要多一些，但不是太夸张。表1是产品的大类。表2是每类产品的型号。表3是每种型号内的具体规格。表4是每种产品的参数规则，每个参数都有具体的参数值，少的没有或者1,2个，多了不超过 10个。表5，列举了其中一个产品的...(more)

最佳实践应该是没有的 但是有统一的科班的套路，你可以先看执行计划 根据不同的情况进行不同的优化，然后也有统一的目的 就是最小化io

总结一个重要的就是存放的数据尽量小，每条记录尽量小

从上图大概看到cpu IO wait较高，建议在机器总体内存允许的情况下，扩大user data所在的bufferpool，同时监控bufferpool命中率，逐步调优。系统表的大量LOCK WAIT肯定会导致系统总体运行变慢，SQL不能及时得到处理，应用的SESSION不断的连接进来，数据库会被压垮，这也就是你通过VMSTAT ...

v$rman_status、v$rman_backup_job_detailsselect s.status as \"备份状态\",       b.INPUT_TYPE as \"备份类型\",       to_char(b.START_TIME,\'yyyy-mm-dd hh24:mi:ss\') as 总的开始时间,       to_c...