今天做数据迁移, 发现事务有时候可以回滚, 有时候不可以回滚, 最后一点点调试发现中间有段修改表结构的语句, 最终导致回滚失败. 1.MySQL最常用的两个表类型: InnoDB和MyISAM.MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持,而InnoDB提供事务支持.存储过程.视图.行级锁定等等高级数据库功能,若回滚失败,先检查表类型. SHOW ENGINES 语句可以查看当前的数据库支持的存储类 SHOW CREATE TABLE 表名;可以查看表的

1.场景描述 早上7:25 接到Report中心同学告警,昨天业务报表数据没有完整跑出来,缺少500位业务员的数据,并且很快定位到,缺少的是huabei_order库上的数据.Report中心的数据是BI每天5:15从huabei_order库的从库上抽取.查看监控告警,从库实例确实在4:50 --6:00 有延迟,但已恢复.数据不完整,直接原因就是主从延迟. 7:55 请求BI重新抽取数据,重新生成报表. 8:20 报表数据验证无误. 问题还没结束: 忽略监控告警的不及时.不完整. 还需要回答

move 和shrink 的共同点1.收缩段2.消除部分行迁移3.消除空间碎片4.使数据更紧密 shrink 语法:  alter table TABLE_NAME shrink space [compact|cascate] segment shrink执行的两个阶段:1.数据重组(compact): 通过一系列insert.delete操作,将数据尽量排列在段的前面.在这个过程中需要在表上加RX锁,即只在需要移动的行上加锁.由于涉及到rowid的改变,需要enable row movemen

如果您不了解ALTER TABLE的语法,可以先参考: http://dev.mysql.com/doc/refman/5.1/en/alter-table.html 使用ALTER TABLE 可以修改一张表的结构.比如,添加或者删除一个字段,创建或者删除一个索引,修改一个字段的类型,或者重命名一个字段,或者表的一些元信息.我们还可以通过ALTER TABLE来修改表引擎. 在大多数情况下,ALTER TABLE通过建立一个原表的拷贝,并在拷贝上修改,然后删除原表,最后修改拷贝的名称为原表名来

问题描述: 今天处理切换分区数据的时候出现了这个错误: 消息 4900,级别 16,状态 2,第 1 行 对表 'XX.XXX' 执行 ALTER TABLE SWITCH 语句失败.对于已启用更改跟踪的表,不可能切换其分区.请先禁用更改跟踪,再使用 ALTER TABLE SWITCH. 显示开启了跟踪需要先关闭才能切换分区 解决方案: 1.为数据库或表禁用更改跟踪 必须首先为所有启用了更改跟踪的表禁用更改跟踪,然后才能将数据库的更改跟踪设为 OFF. 若要确定数据库中哪些表启用了更改跟踪,请

*/ .hljs { display: block; overflow-x: auto; padding: 0.5em; color: #333; background: #f8f8f8; } .hljs-comment, .hljs-template_comment, .diff .hljs-header, .hljs-javadoc { color: #998; font-style: italic; } .hljs-keyword, .css .rule .hljs-keyword, .h

--===================================================================== 事件起因:开发发现有表插入数据失败,查看后发现INT类型自增值已经到了最大值,无法继续插入,需要修改INT类型为BIGINT类型. --===================================================================== 作为一群自认为还算有点经验的老DBA,大家相互商量下,决定删除复制,然后禁止访问

mysql的alter table操作的性能对打表来说是个大问题. mysql执行大部分修改表结构的方法是用新的结构创建一个空表,从旧表中查出所有的数据插入新表,然后删除旧表.这样操作就可能需要花费很长时间,如果内存不足而表又很大,而且还有很多索引的情况下尤其如此. 一般而言大部分AlterTable操作将导致mysql服务中断. 不是所有的alter table操作都会引起表重建 alter table允许使用alter column,modify column和change column语句

企业进行对数据库执行刷数据工作,一段很长的语句希望同时成功或者失败时用到. 1.建立测试环境 /************************************************************ * Code formatted by SoftTree SQL Assistant ?v6.5.278 * Time: 2016/9/29 21:33:55 ************************************************************/

首先我建议你在对MySQL表做DDL操作时: 1 执行 show processlist 查看,要操作的表(数据库对象)是否处于锁状态 if("未锁定") { 执行DDL语句 }else { 三思后行 } 作为一个程序猿,随着开发的进行,我们要面临需求的变更. 随之而来的有可能就是表结构的变化--字段的增加,字段数据类型的更新. 此时此刻,我就在Alter Table面前跪了. My Sql 中 Waiting for table metadata lock,主要发生在你在Alter

--需求有变,需要往t_login表的f_userName字段添加外国人名,之前设置的varchar(10)不够,商议决定改成varchar(30),执行的时候,提示消息 索引'uq_f_userName' 依赖于 列'f_userName'.由于一个或多个对象访问此列,ALTER TABLE ALTER COLUMN f_userName 失败.--原来,之前为了防止f_userName重复,添加了唯一索引uq_f_userName.--进行如下操作后,问题妥妥解决--表名:t_login(登

在MySQL5.5和之前版本,在运行的生产环境对大表(超过数百万纪录)执行Alter操作是一件很困难的事情.因为将重建表和锁表,影响用户者的使用.因此知道Alter操作何时结束对我们是非常重要的.甚至当执行Create index的时候.如果启用了 fast_index_creation,则不会重建表,但是仍然会锁表.fast_index_creation特性引进在MySQL5.5和更高版本里.在MySQL5.1中如果使用了innodb plugin则也可以使用该特性.   自从MySQL5.6

DB2 alter:add/delete/reset   column 1.添加字段 alter table [table_name] add [column_name] [column_type] 2.更改字段类型 alter table  [table_name] alter column [column_name] set data type  [column_type] 注意: 更改字段类型是有限制的,如将字段改为比之前类型长度大的可以,如果要改小或者修改小数点长度,必须先drop掉原来

在表格被建立在资料库中后,我们常常会发现,这个表格的结构需要有所改变.常见的改变如下: 加一个栏位 删去一个栏位 改变栏位名称 改变栏位的资料种类 以上列出的改变并不是所有可能的改变.ALTER TABLE 也可以被用来作其他的改变,例如改变主键定义. ALTER TABLE 的语法如下: ALTER TABLE "table_name" [改变方式]; [改变方式] 的详细写法会依我们想要达到的目标而有所不同.再以上列出的改变中,[改变方式] 如下: 加一个栏位: ADD "

SparkSQL从2.0开始已经不再支持ALTER TABLE table_name ADD COLUMNS (col_name data_type [COMMENT col_comment], ...)这种语法了(下文简称add columns语法).如果你的Spark项目中用到了SparkSQL+Hive这种模式,从Spark1.x升级到2.x很有可能遇到这个问题. 为了解决这个问题,我们一般有3种方案可以选择: 启动一个hiveserver2服务,通过jdbc直接调用hive,让hive执

部分生产环境采用mysqldump --single-transaction的方式在夜间进行数据库备份,而同事恰好在备份期间执行了alter table操作,操作部分成功部分失败,为啥呢? 在mysqldump对single-transaction参数的解释为: Creates a consistent snapshot by dumping all tables in asingle transaction. Works ONLY for tables stored instorage eng

在上篇<MySQL--当mysqldump --single-transaction遇到alter table>中测试发现,在MySQL 5.6版本中,如果在mysqldump期间修改表,可能会导致mysqldump报错,而该结论与同事的执行现象不符,因此在MySQL 5.5版本中进行下测试. 测试环境: MySQL 5.5.14 在数据库testdb01下有表tb1001,当前表中存有两条数据: ##==============================================

MySQL:5.6.35 OS:redhat5.8 今天更新数据库某些表字段,有如下两SQL: ①alter table xx modify xxxx;(表大概是77w) ②alter table sb add sbsb;(表大概是95w) 奇怪的是①产生的state为:copy to tmp table ②产生的state为:altering table 两表同样是百万级别的:后者执行虽慢,但是消耗时间不到1200s,而后者跑了2800s. 开始怀疑alter中的add 和modify 两个操

1.L_Monitoring有这么些字段,ID,Collecttime,PlateType,PlateNO以及其他一些这段.建立这个表的时候是个非分区表,其中ID是主键,并在Collecttime,PlateType,PlateNO上面建立了索引.2.系统运行一阵子后,L_Monitoring数据变得非常大,5,6千万,而且后续还会更大.所以要求将L_Monitoring表进行分区.分区方案是按照Collecttime进行每天分区.Collecttime为分区字段,并将Collecttime字段

通常情况下,修改表的结构一般不会有太大问题,无非就是一个 alter table 操作,但是对于大表做 alter 操作是一个大问题,请小伙伴们慎重. mysql执行大部分修改表结构操作方法是创建一个空表,从旧表查询所有的数据插入,然后删除旧表.如果内存不足,或者表很大,而且还有很多索引的情况下,可能需要花费数个小时,甚至数天才能完成.所以如果是操作线上数据库,甚至会影响到服务的正常进行,操作一定要慎重.如有需要可以查询其他方法操作进行. 在这里,如果是修改列的默认值的话,是有一个小技巧的.列的