月归档：七月 2011

oracle 10g flashback

发表于 2011 年 7 月 21 日 由 惜分飞

一、oracle falshback drop
利用flashback drop oracle10g可以对DDL操作进行恢复,oracla提供类似回收站的recyclebin来收集被删除的对象，其实对象在删除的时候oracle把对象写到一个数据字典表中，当用户不需要该对象的时候，可以利用purge命令来从回收站进行清除
select object_name,droptime,dropscn,purge_object,ORIGINAL_NAME from recyclebin;
flashback table f_drop to before drop;
清空回收站：
1）清空一张表：purge table “BIN$N+i42FTvSSemvMrH6frCQg==$0″/table_name;
2）清空一个index：purge index index_name;
2）清空所有对象：PURGE recyclebin;

二、oracle falshback table
对于误drop的table此可以使用本操作，还原drop的table
select t_odu.*,ora_rowscn from a;–查询每条记录对应scn
select dbms_flashback.get_system_change_number from dual;–系统当前scn
alter table t_odu enable row movement;–table row movement
flashback table t_odu to scn 1831189;–基于scn恢复
flashback table t_odu to timestamp to_timestamp(’2011-6-27 11:45:20′,’yyyy-mm-dd hh24:mi:ss’);–基于时间点
scn补充：
可以通过select ora_rowscn from table 得到每一条结果集当前的SCN，timestamp_to_scn()将scn转换到stmestamp；scn_to_timestamp()将timestamp转换到scn。

三、oracle falshback version query
racle10g falshback 能将所有做了提交的行进行记录，就类似于审计的功能，通过falshback可以查询什么时候执行了什么操作，非常方便，包括闪回版本的查询和审计等
select COUNT(*) from t_query as of scn 1831544;
SELECT COUNT(*) FROM t_query as of timestamp to_timestamp(’2011-07-21 14:58:00′,’yyyy-mm-dd hh24:mi:ss’);

四、oracle falshback transaction query
回闪事务功能提供对过去某段时间内所完成的事务的查询和撤销
SELECT * FROM flashback_transaction_query a WHERE a.table_name=’T_QUERY’;
补充：
UNDO_SQL 就是当时对表T_QUERY的逆向操作语句

发表在 Oracle备份恢复 | 一条评论

performing DML/DDL operation over object in bin错误模拟

发表于 2011 年 7 月 21 日 由 惜分飞

1、alert文件中现象
Thu Jul 21 09:49:38 2011
performing DML/DDL operation over object in bin.
Thu Jul 21 09:51:02 2011
performing DML/DDL operation over object in bin.

2、开始模拟
1）确认回收站功能启用
SQL> show parameter recyclebin;

NAME TYPE VALUE
———————————— ———– ——————————
recyclebin string ON
如果是OFF，使用alter system set recyclebin=on;开启回收站功能

2）创建和删除表
SQL> create table t_drop
2 as
3 select * from tab;

Table created.

SQL> drop table t_drop;

Table dropped.
SQL> show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
—————- —————————— ———— ——————-
T_DROP BIN$qIuF4JHvDJDgQKjADAsarA==$0 TABLE 2011-07-21:09:46:52

3）查看回收站表中数据
SQL> select * from “BIN$qIuF4JHvDJDgQKjADAsarA==$0″;

TNAME TABTYPE CLUSTERID
—————————— ——- ———-
T TABLE
TAB_CRM_CLIENT TABLE
TEST_COUNT TABLE
V_TEST VIEW
TEST TABLE
T_DROP TABLE
TAB_OLCM TABLE

7 rows selected.

4）对回收站中数据进行dml操作
SQL> delete from “BIN$qIuF4JHvDJDgQKjADAsarA==$0″;
delete from “BIN$qIuF4JHvDJDgQKjADAsarA==$0″
*
ERROR at line 1:
ORA-38301: can not perform DDL/DML over objects in Recycle Bin

5）对回收站中数据进行ddl操作
SQL> drop table “BIN$qIuF4JHvDJDgQKjADAsarA==$0″;
drop table “BIN$qIuF4JHvDJDgQKjADAsarA==$0″
*
ERROR at line 1:
ORA-38301: can not perform DDL/DML over objects in Recycle Bin

6）查看回收站，错误重现
Thu Jul 21 09:56:44 2011
performing DML/DDL operation over object in bin.
Thu Jul 21 09:57:19 2011
performing DML/DDL operation over object in bin.

7）说明
由于对回收站中的对象执行了dml或者ddl操作导致alert报类此做。在回收站中不能执行ddl或者dml操作

发表在 Oracle | 评论关闭

innobackupex增量备份测试

发表于 2011 年 7 月 19 日 由 惜分飞

1、全备
/opt/mysql/product/5.5/bin/innobackupex –defaults-file=/etc/my.cnf –no-timestamp –socket=/var/run/mysqld/mysqld.sock –user=root –password=passw0rd /opt/mysql/mysql_bak/full
2、修改库中数据
mysql> create database fei;
Query OK, 1 row affected (0.03 sec)
mysql> use fei;
Database changed
mysql> create table t_1 as select * from information_schema.tables;
Query OK, 83 rows affected (0.20 sec)
Records: 83 Duplicates: 0 Warnings: 0
mysql> create table t_2 as select * from information_schema.tables;
Query OK, 84 rows affected (0.03 sec)
Records: 84 Duplicates: 0 Warnings: 0
mysql> create table t_3 as select * from information_schema.tables;
Query OK, 85 rows affected (0.04 sec)
Records: 85 Duplicates: 0 Warnings: 0

3、增量备份
/opt/mysql/product/5.5/bin/innobackupex –defaults-file=/etc/my.cnf –no-timestamp –socket=/var/run/mysqld/mysqld.sock –user=root –password=passw0rd –incremental –incremental-basedir=/opt/mysql/mysql_bak/full /opt/mysql/mysql_bak/inc

4、恢复全备
/opt/mysql/product/5.5/bin/innobackupex /opt/mysql/mysql_bak/full –apply-log

5、恢复增量备份
/opt/mysql/product/5.5/bin/innobackupex /opt/mysql/mysql_bak/full –incremental –incremental-dir=/opt/mysql/mysql_bak/inc –apply-log

6、还原数据库到默认目录
/opt/mysql/product/5.5/bin/innobackupex –defaults-file=/etc/my.cnf /opt/mysql/mysql_bak/full/ –copy-back

7、启动数据库测试
结论为：所有新创建的对象都没恢复成功
后来创建的库和表结构都不存在，在执行增量恢复的时候，有如下错误提示：
110719 11:49:57 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: error: cannot open /opt/mysql/mysql_bak/full/fei/t_2.ibd
xtrabackup: Error: xtrabackup_apply_delta() failed.
xtrabackup: page size for /opt/mysql/mysql_bak/inc/fei/t_3.ibd.delta is 16384 bytes
110719 11:49:57 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: error: cannot open /opt/mysql/mysql_bak/full/fei/t_3.ibd
xtrabackup: Error: xtrabackup_apply_delta() failed.
xtrabackup: page size for /opt/mysql/mysql_bak/inc/fei/t_1.ibd.delta is 16384 bytes
110719 11:49:57 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: error: cannot open /opt/mysql/mysql_bak/full/fei/t_1.ibd
xtrabackup: Error: xtrabackup_apply_delta() failed.
fei.*对象是在全备之后创建的，全备份集中并不存在，因此应用增量时就报了错，此时如果原始数据文件已经损坏，那么fei.*的数据就无法恢复了，因为缺少了其数据文件。innobackupex增量备份和恢复功能还不完善，有新增对象时会出错

发表在 MySQL | 一条评论