三、SQL调优
数据库优化主要是DBA的工作，而且调优分成很多步骤，根据经验来看，首先需要调整的就是程序员写的SQL语句，一句不良的SQL，能致使整个Oracle宕机，这并不是夸张的说法，当然也不要根据这个来说明Oracle多么脆弱，首先应该看的是SQL如何优化。
其实在开发环境或测试环境下，有时很难发现真正的性能问题，因为开发环境的数据量可能比生产环境的实际数据量要小很多，即便出现很多的FTS，效率也是可以接受的，这种工作方式，就给调优带来了一定的难度，所以一般都是上线后，由生产系统反馈出了问题，然后程序员再想办法模拟生产环境，从而使问题重现，进而将之解决。
对于比较好的测试方案中一般包括压力测试，其中也包括大数据量测试，可以自己模拟一些大的数据量，然后进行测试，这是比较好的方式。对于调优的方式，首先是使用SQL的执行计划来查看是否使用了正确的索引，如上已经讨论过，如果确认索引有问题，请新建索引从而解决问题，如果已经建立了索引，但是发现索引没有用上，那么可能是表分析不到位，需要重新进行表分析，可以申请DBA进行协助。如果以上两者都做了，还是不能正确利用索引，那么就需要使用hint功能，强制使用索引，此功能比较复杂，不再多说，在实际工作中，可向DBA咨询。
有时SQL是存在于整个系统中的，很难单独提取出来，这时有几个办法：
1．在程序中加断点，当程序运行到SQL处，先把SQL取出来，自己去分析
2．在程序中加输出，把SQL直接输出到外部文件，然后再慢慢分析
3．向DBA申请，打开Oracle的Trace功能，记录所有的SQL语句。不过这种方式会使整个系统的效率降低不少，使用之后，一定记得把参数调整回去。 程序员所能涉及到的就是SQL调优，其它更深入的系统调优，可以不做过多的考虑。
四、多数据库协作
这里所说的数据库，实际上指的是Oracle中常说的“实例”，这些实例可以位于同一台机器上，也可以位于不同的机器上。有时“多数据库”还可以指在同一个实例中不同的用户中，如果所有的内容均在一个实例中进行，只是分属于不同的用户，这种处理方式最简单，只需要在引用的表名前加上其它用户的名字即可，比如 user1想使用user2中的表，可以写成：select * from user2.table_name。
如果觉得在应用程序中每次都要带着其它的用户名不方便或有其它原因，可以有两种方式来替换：
1．视图
Create or replace view table_name as select * from user2.table_name;
这种方式，直接在user1中引用视图，就可以实现对user2中表的引用
2．同义词
Create synonym table_name for user2.table_name;
这种方式相对于视图来说更加专业，一般都是按这种方式来处理，在user1中使用table_name的时候，自动根据同义词定义转到相应的位置。
与视图的另一个区别是，同义词可以对任何的object进行映射，而不仅局限于表，比如package等。所以应该多用这种方式来替代视图的方式。
如果多数据库不在同一个实例中，则需要使用DBLINK进行连接，可以参考create database link的写法，在一般的应用中，很少用到这种方式。
以上的使用有一个默认前提就是user2允许user1来使用它的资源，如果没有权限，user1是不能操作user2的表的，这时就涉及到一个赋权的操作，赋权必须由user2亲自来处理，其它具有DBA角色的用户也不可以代劳。
赋权使用如下语句：grant select on table_name to user1;
有一点需要特别注意，如果user1具有DBA角色，在没有显示赋权的情况下，他也可以直接使用user2中的表，但是如果在user1中写存储过程，在函数中引用user2中的表，必须显示的赋权，这点是非常容易引起混淆的地方，需要提醒特别注意。
五、错误排查
程序写多了，难免会出错，数据库也不例外。出错并不可怕，只要及时找到出错的解决方案就可以了。
在上面已经提起过记录SQL语句的一些做法，当把SQL运行的时候，数据库一般会报一个ora错误，如ora-00600这样的方式，并给出一个简短的说明，但是说明的文字都不会太细致。如何根据这个蛛丝马迹找到问题的所在呢？如果你的数据库服务器位于unix或linux服务器上，你需要telnet登录服务器，系统提供了一个oerr的命令行工具，可以方便的查出错误的具体含义，如 oerr ora 600这种样式。如果你的数据库服务器位于Windows服务器，那么没有这样的工具，只能查看帮助文档了。
虽然用oerr工具可以看到错误的详情，但是经过一段时间的试用后就会发现，其实它所给出的提示也是相对简单的，有些甚至什么都看不出来，那么这时就会用到其它的解决办法：
1．GOOGLE等搜索引擎
这是一个非常经济实惠的解决方案，并且根据搜索引擎的强大功能，可以找到很多的相关资料，说不定看到有人和你有同样的问题，下面紧跟着就是解决办法。
2．Metalink
这是Oracle官方提供的一个收费的网站，用户可以在上面查找资料（海量资料，信息量非常大），如果实在查不到解决办法，还可以提问，会有Oracle的专家负责来解答。这是解决Oracle问题权威的地方，但是缺点就是如果你没有账号的话，就等于零了。
对于有些实在看不懂的错误提示，也可以请DBA协助，因为有些错误提示表面上看是SQL的问题，但是实际上可能是数据库本身引起的。如果你从错误信息中可以直接看到“不能扩展”、“表空间已满”或“回滚段过旧”等显然和SQL无关的错误，就可以直接去寻求DBA的帮助了。
如果您正在部署一个BS结构的系统，很有可能会发现，使用客户端工具连接的时候，与服务器连接一切正常，可就是WEB程序无法连接数据库，并且报告 “OCI需要8.1.7或以上版本”这个错误。这是个比较“暧昧”的错误信息，很显然我们现在所装的客户端都满足它的要求，那到底是哪里的问题呢？问题就在于需要给Oracle的ora92目录赋一个权限，如下图：
如果你尝试做这个授权的时候，你会发现，这个用户已经存在，并且已经授权成功！但是为什么还不行呢？这里需要一个技巧，先把“读取和运行”这个对勾去掉，再选中，然后“确定”，也就是重新做一次赋权，就可以了。根据机器的性能，可能要稍等几秒钟或几分钟。
经过上面的折腾一般就行了。如果还不能正常访问，那么请重新启动WEB服务器（不是数据库服务器），这个问题肯定就能解决了。
对于Oracle10g，没有这个目录，我的做法就是把Oracle整个安装目录全做一下这个授权，就没有问题了。
六、字符集问题
如果数据库服务器是装在中文环境下，客户端也是在中文环境下运行，那么这一部分基本就不用看了。但是如果安装情况比较复杂，特别是服务器需要支持多语言及多字符集的时候，客户端如何配合就成了一个问题。
要想知道客户端怎么配置，就需要知道服务器端是按什么标准来安排的，可以通过以下SQL来查询：
select * from database_properties
其中NLS_CHARACTERSET指的就是服务器端的字符集，比如服务器上查出来的结果是ZHS16GBK，那么客户端就需要按这个标准来配置。对于我们开发人员来说，客户端一般是Windows平台，这个配置需要在注册表中修改，注册表的路径为：我的电脑\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0\NLS_LANG
比如我的机器这个键值就是SIMPLIFIED CHINESE_CHINA.ZHS16GBK（注意保留空格），表示简体中文的中文字符集。从字符集上看，目前服务器与客户端是匹配的，字符集匹配，查询出来的内容就不会是乱码了，否则你将看到很多不愿意看到的文字。
一般为了实现多语言支持，字符集都设成UTF8，这样可以支持多种文字了。如果服务器端与客户端字符集不一致，一般会出问题，但是问题主要都在显示上面，不会对系统有太多的影响，比如俄罗斯录入了当地语言的名字，在中文系统下有可能就显示不出来。
Oracle一共支持多少的字符集呢，我没有数过，如果ZHS16GBK不行，换UTF8试一下，说不定就行了。也有个例外，早期的Oracle有些版本只支持西欧字符集，那是一个单字节的字符集，字节的高位是空的。这个字符集与ZHS16GBK是不兼容的，这时就要把客户端同样设成西欧字符集才可以。字符集之间有包容关系，只要符合这个包容关系，两端设的不一样也没有关系，比如ZHS16GBK和UTF8之间就是包容的。
数据库优化主要是DBA的工作，而且调优分成很多步骤，根据经验来看，首先需要调整的就是程序员写的SQL语句，一句不良的SQL，能致使整个Oracle宕机，这并不是夸张的说法，当然也不要根据这个来说明Oracle多么脆弱，首先应该看的是SQL如何优化。
其实在开发环境或测试环境下，有时很难发现真正的性能问题，因为开发环境的数据量可能比生产环境的实际数据量要小很多，即便出现很多的FTS，效率也是可以接受的，这种工作方式，就给调优带来了一定的难度，所以一般都是上线后，由生产系统反馈出了问题，然后程序员再想办法模拟生产环境，从而使问题重现，进而将之解决。
对于比较好的测试方案中一般包括压力测试，其中也包括大数据量测试，可以自己模拟一些大的数据量，然后进行测试，这是比较好的方式。对于调优的方式，首先是使用SQL的执行计划来查看是否使用了正确的索引，如上已经讨论过，如果确认索引有问题，请新建索引从而解决问题，如果已经建立了索引，但是发现索引没有用上，那么可能是表分析不到位，需要重新进行表分析，可以申请DBA进行协助。如果以上两者都做了，还是不能正确利用索引，那么就需要使用hint功能，强制使用索引，此功能比较复杂，不再多说，在实际工作中，可向DBA咨询。
有时SQL是存在于整个系统中的，很难单独提取出来，这时有几个办法：
1．在程序中加断点，当程序运行到SQL处，先把SQL取出来，自己去分析
2．在程序中加输出，把SQL直接输出到外部文件，然后再慢慢分析
3．向DBA申请，打开Oracle的Trace功能，记录所有的SQL语句。不过这种方式会使整个系统的效率降低不少，使用之后，一定记得把参数调整回去。 程序员所能涉及到的就是SQL调优，其它更深入的系统调优，可以不做过多的考虑。
四、多数据库协作
这里所说的数据库，实际上指的是Oracle中常说的“实例”，这些实例可以位于同一台机器上，也可以位于不同的机器上。有时“多数据库”还可以指在同一个实例中不同的用户中，如果所有的内容均在一个实例中进行，只是分属于不同的用户，这种处理方式最简单，只需要在引用的表名前加上其它用户的名字即可，比如 user1想使用user2中的表，可以写成：select * from user2.table_name。
如果觉得在应用程序中每次都要带着其它的用户名不方便或有其它原因，可以有两种方式来替换：
1．视图
Create or replace view table_name as select * from user2.table_name;
这种方式，直接在user1中引用视图，就可以实现对user2中表的引用
2．同义词
Create synonym table_name for user2.table_name;
这种方式相对于视图来说更加专业，一般都是按这种方式来处理，在user1中使用table_name的时候，自动根据同义词定义转到相应的位置。
与视图的另一个区别是，同义词可以对任何的object进行映射，而不仅局限于表，比如package等。所以应该多用这种方式来替代视图的方式。
如果多数据库不在同一个实例中，则需要使用DBLINK进行连接，可以参考create database link的写法，在一般的应用中，很少用到这种方式。
以上的使用有一个默认前提就是user2允许user1来使用它的资源，如果没有权限，user1是不能操作user2的表的，这时就涉及到一个赋权的操作，赋权必须由user2亲自来处理，其它具有DBA角色的用户也不可以代劳。
赋权使用如下语句：grant select on table_name to user1;
有一点需要特别注意，如果user1具有DBA角色，在没有显示赋权的情况下，他也可以直接使用user2中的表，但是如果在user1中写存储过程，在函数中引用user2中的表，必须显示的赋权，这点是非常容易引起混淆的地方，需要提醒特别注意。
五、错误排查
程序写多了，难免会出错，数据库也不例外。出错并不可怕，只要及时找到出错的解决方案就可以了。
在上面已经提起过记录SQL语句的一些做法，当把SQL运行的时候，数据库一般会报一个ora错误，如ora-00600这样的方式，并给出一个简短的说明，但是说明的文字都不会太细致。如何根据这个蛛丝马迹找到问题的所在呢？如果你的数据库服务器位于unix或linux服务器上，你需要telnet登录服务器，系统提供了一个oerr的命令行工具，可以方便的查出错误的具体含义，如 oerr ora 600这种样式。如果你的数据库服务器位于Windows服务器，那么没有这样的工具，只能查看帮助文档了。
虽然用oerr工具可以看到错误的详情，但是经过一段时间的试用后就会发现，其实它所给出的提示也是相对简单的，有些甚至什么都看不出来，那么这时就会用到其它的解决办法：
1．GOOGLE等搜索引擎
这是一个非常经济实惠的解决方案，并且根据搜索引擎的强大功能，可以找到很多的相关资料，说不定看到有人和你有同样的问题，下面紧跟着就是解决办法。
2．Metalink
这是Oracle官方提供的一个收费的网站，用户可以在上面查找资料（海量资料，信息量非常大），如果实在查不到解决办法，还可以提问，会有Oracle的专家负责来解答。这是解决Oracle问题权威的地方，但是缺点就是如果你没有账号的话，就等于零了。
对于有些实在看不懂的错误提示，也可以请DBA协助，因为有些错误提示表面上看是SQL的问题，但是实际上可能是数据库本身引起的。如果你从错误信息中可以直接看到“不能扩展”、“表空间已满”或“回滚段过旧”等显然和SQL无关的错误，就可以直接去寻求DBA的帮助了。
如果您正在部署一个BS结构的系统，很有可能会发现，使用客户端工具连接的时候，与服务器连接一切正常，可就是WEB程序无法连接数据库，并且报告 “OCI需要8.1.7或以上版本”这个错误。这是个比较“暧昧”的错误信息，很显然我们现在所装的客户端都满足它的要求，那到底是哪里的问题呢？问题就在于需要给Oracle的ora92目录赋一个权限，如下图：
如果你尝试做这个授权的时候，你会发现，这个用户已经存在，并且已经授权成功！但是为什么还不行呢？这里需要一个技巧，先把“读取和运行”这个对勾去掉，再选中，然后“确定”，也就是重新做一次赋权，就可以了。根据机器的性能，可能要稍等几秒钟或几分钟。
经过上面的折腾一般就行了。如果还不能正常访问，那么请重新启动WEB服务器（不是数据库服务器），这个问题肯定就能解决了。
对于Oracle10g，没有这个目录，我的做法就是把Oracle整个安装目录全做一下这个授权，就没有问题了。
六、字符集问题
如果数据库服务器是装在中文环境下，客户端也是在中文环境下运行，那么这一部分基本就不用看了。但是如果安装情况比较复杂，特别是服务器需要支持多语言及多字符集的时候，客户端如何配合就成了一个问题。
要想知道客户端怎么配置，就需要知道服务器端是按什么标准来安排的，可以通过以下SQL来查询：
select * from database_properties
其中NLS_CHARACTERSET指的就是服务器端的字符集，比如服务器上查出来的结果是ZHS16GBK，那么客户端就需要按这个标准来配置。对于我们开发人员来说，客户端一般是Windows平台，这个配置需要在注册表中修改，注册表的路径为：我的电脑\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0\NLS_LANG
比如我的机器这个键值就是SIMPLIFIED CHINESE_CHINA.ZHS16GBK（注意保留空格），表示简体中文的中文字符集。从字符集上看，目前服务器与客户端是匹配的，字符集匹配，查询出来的内容就不会是乱码了，否则你将看到很多不愿意看到的文字。
一般为了实现多语言支持，字符集都设成UTF8，这样可以支持多种文字了。如果服务器端与客户端字符集不一致，一般会出问题，但是问题主要都在显示上面，不会对系统有太多的影响，比如俄罗斯录入了当地语言的名字，在中文系统下有可能就显示不出来。
Oracle一共支持多少的字符集呢，我没有数过，如果ZHS16GBK不行，换UTF8试一下，说不定就行了。也有个例外，早期的Oracle有些版本只支持西欧字符集，那是一个单字节的字符集，字节的高位是空的。这个字符集与ZHS16GBK是不兼容的，这时就要把客户端同样设成西欧字符集才可以。字符集之间有包容关系，只要符合这个包容关系，两端设的不一样也没有关系，比如ZHS16GBK和UTF8之间就是包容的。
好了，说了这么多，都是我在实际工作中的一些感受，希望对大家有益，也希望大家都能成为真正的高手。
本文转自Aicken(李鸣)博客园博客，原文链接：http://www.cnblogs.com/isline/archive/2010/04/08/1706120.html，如需转载请自行联系原作者
