数据库查询异常处理

今天晚上运营同事反馈了系统有个列表数据查询不出来，筛选某个条件又能查出数据来。当运营反馈时，立马收到线上报警邮件提示如下：

也就是抛出 MySQLDataException异常，由于定性思维的原因，一直在排查sql问题，不断尝试替换某个字段的数据拼接查询，最终还是失败了。由于经验较少，不断尝试column '15'这一列，心想没有15这个字段呀（思维方向错误了）。导致问题排查了两个小时；最后联想到INTEGER类型出错，干脆就直接查找mode里的对象与sql查询查询出来的字段作比较，最终发现其实是某个字段数据值长度突然大增（部门其他同事对接大厂时，修改了字段长度，然后我们这边的系统无意识到字段长度，还是使用Integer类型，最终导致异常出现），修改成long类型后解决，但这种修改方法也会随着时间问题变成一个坑。

总结今晚遇到的问题，就是以前菜的坑太少了，导致问题定位错误。错误日志：'1.00000539598E11' in column '15' is outside valid range for the datatype INTEGER翻译过来也就是“15”列中的“1.00000539598E11”超出了数据类型整数的有效范围。不是15那个字段，而是第15列（MB   太SB了）。因此在此做个笔记，以防以后继续犯类似思维错误。

Result.next()只会在两种情况发生异常：一是数据库本身故障，二是已经关闭。

而在你的程序中只是为了防止出现一个异常不影响其它的，那么可以假定了，前面的访问是正确的。所以，第一个异常原因不可能出现的。而你不会自己主动在另一个线程关闭数据库吧？那么第二个异常原因也不可能出现。

所以，这个异常捕获了，不必做任何处理，直接进行下一个就行。

while(rs.next()){

try{

//..........

}

catch(SQLException ex){}

}

SQL Server 2000数据库LDF损坏,只有mdf的恢复方法。

SQL Server 2000数据库文件遭到破坏的现象经常出现，数据库出错是否可以修复呢？答案是可以的，本日志以一个sql server 2000数据库，数据库日志文件ldf损坏了，mdf正常，数据库附加失败的修复方法总结一下，数据库数据恢复在很多时候比较复杂，当数据库存在大量错误的时候，使用DBCC修复也是不可以的，需要拆解数据库来抢救重要的数据，下面是较为常见的一种SQL Server 2000数据库修复方式：

1） 先及时把原来的数据库文件（如test.mdf)备份到其他地方。

2） 停掉服务器。

3） 删除这个test.mdf。

4) 重新建立一个test同名数据库。

5） 删除这个新建立的test数据库的test.ldf文件，并用开始备份好test.mdf文件覆盖这个新建立的test.mdf文件。

6） 启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

.设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”。

7） 设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

8） 下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在 *** 作中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

---