陆陆续续写了四篇和开发同事的代沟，从最开始的吐槽到后面的例行总结，整个过程也是总结经验，看似很小的问题对于DBA来说就是莫大的改进，或者在开发严重越不过去的坎儿在DBA来看就是修改一个简单的配置就可以搞定，这个过程中都是互帮互助，大家互相体谅，才是共赢。
最近顺手帮开发同事解决了几个小问题，也可以暴露出来一些问题。简单总结一下。
数据库连接的问题
首先是数据库连接的问题，这两天四个同事遇到了同样的问题，但是问题原因也是五花八门。
ORA-12514连接数据库的问题
12514, 00000,
"TNS:listener does not currently know of service requested in connect
descriptor"
之前一个开发同事帮我解决了一个安卓软件的问题，当时他随口一问知道我是DBA，就简单在lync上打了个招呼，说以后有数据库问题可以找我。最近还真碰
到数据库问题了，这种帮忙当然是义不容辞，他反馈的问题是连接数据库的时候报错ORA-12514，是windows中使用plsqdev去连接本地的一 个数据库，看这个错误感觉就是网络配置的问题。
xxxx[9:59]:
ORA-12514
监听程序当前无法人别连接描述中的请求的服务
还是解析不了监听
然后他带着电脑过来了，我简单看了下，监听也启动了，按照他所说，数据库服务也配置了，他使用了netmgr和netca中的图形配置，看起来这个问题是 不是windows上的某些奇怪的问题，按照他所说，这些配置都完成了，但是数据库就是连接不了，我使用cmd进入命令行，如果是linux可以直接运行 一个ps -ef|grep smon来看看数据库的一些简单配置，但是windows下查看还是不够直接，怎么看呢，我直接在cmd里运行services.msc进行服务列表，查 看启动的oracle服务看看实例到底是哪一个，结果找了一圈，没找到，最后反复确认，发现原来这个同事没有使用dbca创建数据库实例，当然我给他简单 解释了一下，然后直接进入dbca界面帮他创建，看着sysdba可以正常连接到实例，这个问题的解决就告一段落了。通过这个可以反映出开发人员对于数据 库实例的概念还是不够清晰。
ORA-12154的问题
12154, 00000,
"TNS:could not resolve the connect identifier specified"
这是另外一个开发同事反馈的，也是在lync上他找到我说，数据库现在连接有个问题，想让我帮忙看看。当然这个环境不是本地的，而且要访问他们的环境非常困 难，所以可以使用远程桌面来做。最开始的猜测是网络的端口的问题，因为对于应用来说，开放的端口都是指定的。他在本地给我简单复现了这个问题，我说直接看 tnsnames.ora的配置。
然后查找了一番，找到了这个配置
ORCL_TESTDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = xxxx.67(PORT = 1523))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = testdb)
)
)
这个时候一眼就看出了问题，这是配置的问题，这个同事折腾了好半天，这个Host的配置没有正常结尾，所以补全之后问题就解决了。当然解释了一通，最终说键值对他马上就理解了。
第二个ORA-12154的问题
然后在下午的时候，另外一个开发同事找到我说，有一个数据库配置比较奇怪，怎么都弄不好，还说感觉里面的一个数据库配置会影响到另外一个，一直也没找到解决方法。让我帮忙看看。
当然这个问题也是在内网环境，也是远程协助，看到她复现了一遍问题，发现是tnsnames.ora里面的一个配置多了一项配置。
比如test的配置信息如下：
test=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST =
xxxxxx)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =
test)))
她那边的配置信息为：
test=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = xxxxxx)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = test)（sd=e)))
这与最后的sd=e是怎么来的，她也记不清了，我可以猜出来以前应该是sid=test可能最后不知道怎么修改成了现在的模样了。当然这个问题看起来非常简单，但是能够折射出对于数据库层面的一些知识，开发还是不够了解。
最后一个是jdbc连接数据库的问题。开发有个同事反馈说有一个备库连接的时候报了错误。然后提供了以下的错误信息，而且还诚意满满附了日志，我打开日志的瞬间就后悔了，因为这个日志好几十M，其实这个问题确定ip就可以基本判定问题。
[2016.01.28
07:18:10.548]org.springframework.jdbc.CannotGetJdbcConnectionException: Could
not get JDBC Connection; nested exception is
com.atomikos.jdbc.AtomikosSQLException: Failed to grow the connection pool
当然后面确认了IP，发现这个问题的原因在于这个是10gR2的环境，备库是在mount状态，平时有一些大查询需要在凌晨开放给一些应用，但是这个备库 最近重新做了系统，所以原有的crontab 没有正式运行，也就意味着凌晨的查询窗口没有开启，所以这个问题简单确认了一下就明白了问题的原委，当然后续我也提出了一些更多的建议。
说完数据库的连接问题，再来看两个小案例，这个其实也可以和开发的同学好好聊聊。
我收到了一个开发同事的工单，说需要给一个表增加一个列，看起来需求很简单也很明确，而且给出了完整的语句和环境。看起来剩下的就是DBA来执行了。语句类型下面的形式
alter table user_details add (user_time date);
这个需求看起来还是比较简单的，但是我已查看表user_details的情况，里面有近10亿的数据，这样一个大表而且还没有分区的情况下做一个字段的
添加，影响还是非常大的。在exadata上做了一个类似的测试发现这种场景都很让人头痛。所以我们的建议是最好不要加。如果一定要加，需要申请维护时间
来做。在线操作就是给自己找虐。当然和开发沟通之后他们内部也做了调整。
然后还有一个问题是一个查询需求，开发提供了一个语句，让我们帮忙查看一下一个统计表中的数据分布情况。
提供的语句类似下面的形式。
select count(*) from TESTSTAT.user_details_info where trunc(regdate,'dd')>=to_date('2014-12-01','yyyy-MM-dd')
and trunc(regdate,'dd')<=to_date('2014-12-31','yyyy-MM-dd');
这样一个查询，表里的数据是非常大的，而且分析表的情况，发现regdate有一个索引字段，但是根据这个查询似乎性能也好不到哪里去。
所以这个语句可以简单调整一番，变成下面的形式。语句的性能就会好很多。
select count(*) from TESTSTAT.user_details_info where regdate
between to_date('2014-12-01','YYYY-mm-dd') and
to_date('2014-12-31','YYYY-mm-dd'); ;
当然这个部分其实还是可以和开发沟通一下，这些看似非常值得注意的小细节如果在开发中引起重视，那么后期的sql问题也会大大减少。