MySQL5.7 datetime无法设置默认值为0

在mysql5.7以上版本中,如果datetime默认值为0,则会出现下面的错误:

ERROR 1067 (42000) at line xxx: Invalid default value for 'xxx'

这是因为mysql5.7调整了校验规则,修改一下/etc/mysql/my.cnf配置文件就可以了

[mysqld]
#默认规则
#sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
sql-mode="ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

然后重启mysql就可以啦。

not in 优化为 not exists

最近迁移数据库的时候,发现not in比not exists效率差太多了

--not in 直接卡死
insert into table1(
select * from table2 t2@oraclegate where t2.pk not in (select pk from table3 t3));

--not exist则很快处理完成
insert into table1(
select * from table2 t2@oraclegate where not exists (select pk from table3 t3 where t3.pk=t2.pk));

其实数据量并不大,不知道是不是用gateway的问题。

SQL Server:提供的值不是数据类型datetime的有效实例

今天遇到了一个很郁闷的问题,在向SQL Server做Insert时,有几条数据总是提示:
提供的值不是数据类型 datetime 的有效实例

然后根据
参数 131 (“”)
还以为提供的数据为空,查了半天。

最后发现,是提交的日期范围,超出了SQL Server的Datetime的范围。
这提示能再坑一些吗。。。

Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: 传入的表格格式数据流(TDS)远程过程调用(RPC)协议流不正确。参数 131 (""): 提供的值不是数据类型 datetime 的有效实例。请检查源数据中的无效值。例如,小数位数大于精度的数值类型的数据即为无效值。
	at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatement(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.doExecute(Unknown Source)
	at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
	at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeUpdate(Unknown Source)
	... 45 more

关闭和打开Oralce10g自动收集COB信息

前几天,发现平台的一支程序突然运行的很慢,经分析后,发现是数据库查询变得超级慢。
用OB9分析后,发现索引正常,没办法最后重启了数据库后,速度直接飚上来了。
但好景不长,第二天早上4点后,又变成龟速,只好找公司DBA帮忙分析问题。

最后发现是Oracle的自动统计分析Job,每天自动进行统计,然后优化器就不走索引,而走统计分析的结果。
而我们的表有较多的删除操作,很快统计分析的结果就不可靠了,结果速度很快就下来了。

最后,禁用之,搞定:)

--状态查询
select * from Dba_Scheduler_Jobs where JOB_NAME ='GATHER_STATS_JOB'

--sysdba
--关闭
exec dbms_scheduler.disable('SYS.GATHER_STATS_JOB');

--sysdba
--启用
exec dbms_scheduler.enable('SYS.GATHER_STATS_JOB');

Oracle11g导入到Oracle10g

1、导出

set PATH=D:\Oracle11g\product\11.2.0\dbhome_1\BIN;%PATH%

expdp USERID/PWD schemas=XXX VERSION=10.2 DIRECTORY=data_pump_dir DUMPFILE=XXX.dmp LOGFILE=exp.log

pause

2、导入


set PATH=D:\Oracle11g\product\11.2.0\dbhome_1\BIN;%PATH%

impdp USERID/PWD schemas=XXX DIRECTORY=data_pump_dir DUMPFILE=XXX.dmp LOGFILE=imp.log

pause

Oracle中大字容量字段

LONG
可变长的字符串数据,最长2G,LONG具有VARCHAR2列的特性,可以存储长文本一个。
表中最多一个LONG列

LONG RAW
可变长二进制数据,最长2G

CLOB
字符大对象Clob 用来存储单字节的字符数据

NCLOB
用来存储多字节的字符数据

BLOB
用于存储二进制数据

BFILE
存储在文件中的二进制数据,这个文件中的数据只能被只读访。但该文件不包含在数据库内。
bfile字段实际的文件存储在文件系统中,字段中存储的是文件定位指针。
bfile对oracle来说是只读的,也不参与事务性控制和数据恢复。
  
其中CLOB,NCLOB,BLOB都是内部的LOB(Large Object)类型,最长4G,没有LONG只能有一列的限制。

Oracle ORA-01461

昨天做联调时,在10g上测试一点儿问题都没有,但切到9i的库上,却直接报错:

ORA-01461:仅可以为插入 LONG 列的 LONG 值赋值

查找资料后发现,是Oracle9i的一个bug,当Clob字段长度在1000~2000之间时,
就会出现这个错误。

解决方法有两个:
1、替换驱动为神奇的版本ojdbc14-10.2.0.3.0.jar,可以避免这个问题。
2、利用Spring+Hibernate解决这个问题

EventSendInfo.hbm.xml

-<property name="MSG" type="java.lang.String">
+<property name="MSG" type="org.springframework.orm.hibernate3.support.ClobStringType">

applicationContext.xml

...
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
...
+<property  name="lobHandler"  ref="oracleLobHandler"/> 
</bean>

...
+<bean id ="oracleLobHandler" class ="org.springframework.jdbc.support.lob.OracleLobHandler" lazy-init ="true">  
+<property name ="nativeJdbcExtractor"  ref ="nativeJdbcExtractor"/>
+</bean >     
+<bean id ="nativeJdbcExtractor" class ="org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtractor" lazy-init="true"/>

...

Oracle的DBF文件减肥

使用OB9,DBA身份登录:
表空间信息-》双击需要RESIZE的表空间-》定义信息-》修改大小后-》创建

或者用SQL:

--枚举DBF文件
SELECT * FROM dba_data_files
--缩小文件
ALTER DATABASE DATAFILE 'DBF_FILE_PATH' RESIZE 512m

常见错误:
ORA-03297: 文件包含在请求的RESIZE值以外使用的数据
这个错误产生的原因是,虽然DBF文件使用率很低,但一些数据存储在了RESIZE值以外,
无法直接进行缩小DBF文件的操作。

要么把数据导出,缩小DBF文件后倒入,再倒入;
要么需要查出哪些表和索引在RESIZE值以外,移动到临时空间后,进行RESIZE操作,再移动回来。