公司最近有一批老产品返修。有一部分功能为方波发生。使用原理的如下
 
使用电子森林的在线仿真 。这个网站仿真的优点是可以看到电流的流向，方便初学者深入理解电路。（网站 https://www.eetree.cn/war/circuitjs.html?lang=cn）
 百度了一下，这个电路叫多谐振荡器双闪灯电路（来源 电巢https://xw.qq.com/cmsid/20200922a0aovj00 ），其他文章也有讲到这个电路但是细节没有这个电路讲的清晰。（电子发烧友 http://www.elecfans.com/article/88/131/189/2020/202004171206214.html）
 电巢的解析看的时候，有一个点不理解，查看《新概率模拟电路》三级管部分后理解。（这本书非常推荐，理论和实践结合，比喻也非常恰当。和国内其他教材完全不同。）
 1.两个三极管不完全对称，流过两个管子的电流一定是不对称的。设Ib1>Ib2,经过电容反馈，V2 的基级电压会小于V1基级电压。为什么电容会正反馈？
 答：Ib1 > Ib2，则C1左边对地点位低于C2右边对地点位。电容两端电压不会突变，则C1右边点位低于C2左边点位，即V1的集电极电位高于V2集电极电位。三极管工作在放大区，Ice2 < Ice1 相当于 等效Rce2 增大，导致C2右端电压上升（电阻增大，分压增大），再根据电容两端电压不会突变，C2左边电压也上升，如此形成正反馈。
 
工作原理简述
 1.上电瞬间 两个三极管处于放大状态。由于两部分电路的不完全对称性，导致流过三极管集电极（放大状态下，基级电流和集电极电流是倍数关系）的电流不同，再通过电容正反馈，使一个电流（基级）增大，一个电流减小。
 2.当正反馈一段时间后，其中一个三极管的集电极会高于Vbe ，此时 这个三极管处于饱和状态 ,Uce 很小（即数电中的开关作用）。
 3.此时，处于饱和三极管上方的电容一端对地点位为零，由于电容两端电压不能突变，此电容另一端（电容和三极管集电极）对地相当于负电位，导致对应三极管处于截至状态。
 4.对地负电位电容通过和三极管基级相连的电阻得到电子，提升对地电位（通过观察波形，实际使电容对外放电，电容两端电压下降）。当使电容和三极管集电极相连的端子对地（即此时这个电容的另一个端子和地相连）电位高于Vbe(三极管起开关作用时集电极和发射极电位差)，另一个三极管导通（即饱和状态）重复状态3。系统开始震荡
 
 
图一 multisim14 仿真原理图
 
 图2 两电容 四端子对地电位（粉绿为一对电容 蓝黄为另一对）
 
 图3 一电容两端电位和流过电容的电流（两者标度不一致，红色为电流，粉色为电压，）
 
补充：
 1.三极管 4种状态 （摘自新概念模电）
 (1）截止状态 晶体管没有明显的电流，Ibq很小，导致Icq很小 “像”没有导通一样。
 一般，当发射结零偏或反偏，而集电极反偏即为截止状态
 (2)放大状态 Ibq合适 且满足Icq=βIbq.在输出伏安特性图中，静态工作电处于放大区。
 一般，当发射结正偏，且集电极反偏时，三极管处于放大状态
 (3)饱和状态，Uce < Uces 在饱和状态下，再增加Ibq Icq则几乎不再增加。这是饱和唯一的关键特征。
 一般情况下 当发射结正偏 集电极反偏 为饱和状态
 (4)倒置状态 。当将发射极和集电极装反时的状态，此时β衰减的特别厉害。
 
2.集电极对应的电阻应比较大，不然可能出现上电即饱和状态，导致没有办法发生震荡
 
 图4 集电极对应的电阻应比较小的情况
 3.multisim14 仿真的坑 蓝灯的压降是3.7V 如果电路中使用发光二极管 注意发光二极管的参数，导通电压和导通电流
 另，有分析的不正确的地方，欢迎各位指出。我们一同学习，一同进步。

 
Oracle闪回
 
作用：自动基于磁盘的备份与恢复，能把表恢复到过去的某个时间点或者SCN。
 
1.查看闪回区
 
SQL>show parameter db_recovery_file_dest; 查看闪回区详细信息
 
SQL> select flashback_on from v$database;   查看闪回区是否开启
 
2.修改闪回功能
 
SQL> startup mount;                                    数据库启动到mount下
 
SQL> alterdatabase flashback on (off);          开启关闭闪回区
 
注：如遇到38706事件错误，可能是因为归档不正确。先启用数据库归档。
 
SQL> alter database archivelog；
 
SQL> alter systemset db_flashback_retention_target=2880；
 
修改闪回时间，默认是1440分钟(1天)，闪回时间是指数据库能回退的时间。
 
3.闪回使用实例：(注：sys用户下不可用闪回)
 
3.1 闪回drop的表
 
在非sys用户下创建表和表上索引，插入相关数据
 
create table abc (fnumber(9));
 
create index idx_teston abc(f);
 
insert into abc values(1);
 
insert into abc values(2);
 
insert into abc values(3);
 
3.2 删除表
 
drop table abc;
 
3.3 删除表之后，表并没有被真正删除，而是重命名之后放在同一用户下的回收站内，同时表上的索引等也会被如此处理。回收站满后以先进先出的原则管理。
 
查看表语句        select* from tab;
 
查看索引语句    select index_name, index_type, table_name from ind;
 
查看回收站语句 show recyclebin;
 
清空回收站语句 PURGE RECYCLEBIN;
 
注：没有放入回收站的表不能被闪回
 
3.4 闪回之后，即可再次看到表，但是表闪回后相应的索引等需要重新编译。
 
flashback table abc to before drop;
 
3.5 闪回DML语句
 
Flashback table abc to timestamp to_timestamp(‘2014-02-14 16:00:00’,’yyyy-mm-dd hh24:mi:ss’)
 
闪回可能会遇到08189错误，执行下列语句
 
alter table test varchar enable row movement;
 
意思是允许Oracle修改rowid。Oracle插入数据时会为该条数据分配唯一rowid并且不变，要启用闪回功能必须开启可修改rowid功能
 
闪回DML数据是使用回滚段进行恢复
 
附：查询所有可以撤消的操作，该操作依赖于undo_retention
 
SELECT versions_xidas xid,
 
versions_startscn,
 
versions_endscn,
 
versions_operation
 
FROM scott.abcVERSIONS between scn minvalue and maxvalue
 
查询undo_retention参数
 
该参数保存了回滚段数据保存的秒时间,超过该时间则无法闪回。默认为15分钟
 
修改该参数 alter system set undo_retention=3600;

 
Oracle10g引入的闪回技术包含
 
1闪回查询(flashback
 
query)
 
2闪回版本查询(flashback version query)3闪回事务查询(flashback
 
transcation query)
 
4闪回表(flashback table)
 
5闪回删除(flashback drop)6闪回数据库(flashback database)。
 
其中闪回查询、闪回版本查询、闪回事务查询属于行级闪回。这三种闪回技术全部依赖于undo表空间中的undo数据。
 
闪回表、闪回删除属于表级闪回。闪回表也是从undo中读取数据，闪回删除是依赖recyclebin
 
闪回数据库属于数据库级闪回。
 
Flashback query是最基本的闪回功能，直接利用回滚段中的旧数据构造某一个时刻的一致性数据版本。只适合单个表数据恢复。对事务中相关多表数据恢复不适合，无法确保相关数据的参照完整性。Flashback query不需要使用resetlogs打开数据库。闪回查询让你能够看到过去某个时间的的数据。能够让你查看和重构以为意外被删除或者该表的数据。你可以根据SCN号和具体时间进行数据库查询。参数undo_retention表明在回滚段中旧的信息被覆盖之前保留的时间。通过使用AS OF字句，你可以查询一个表中不同时段的快照。
 
AS OFSpecifyASOFto retrieve the single version of the rows returned by the query at a particular change number (SCN) or timestamp. If you specifySCN, thenexprmust evaluate to a number. If you specifyTIMESTAMP, thenexprmust evaluate to a timestamp value. Oracle Database returns rows as they existed at the specified system change number or time.---指定AS OF能够通过指定的SCN或者时间戳来获取所有行的单个版本，如果你指定SCN，则后面必须跟数字，如果你指定timestamp，则后面必须指定一个具体时间，Oralce数据会返回在该时间点或者SCN号时的数据。
 
根据SCN的闪回查询：
 
1、初始化数据
 
SQL> create table t(a number,b number);
 
Table created.
 
SQL> insert into t values(1,1);
 
1 row created.
 
SQL> insert into t values(2,2);
 
1 row created.
 
SQL> insert into t values(3,3);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
2、查询当前时间、当前SCN号
 
SQL> alter session set nls_date_format='yyyymmdd hh24:mi:ss';
 
Session altered.
 
SQL> select sysdate from dual; ---获取当前时间
 
SYSDATE
 
-----------------
 
20140313 22:37:48
 
SQL> select dbms_flashback.get_system_change_number from dual; ---获取当前SCN
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1136165
 
3、删除部分数据
 
SQL> delete from t where b=3;
 
1 row deleted.
 
SQL> commit;
 
Commit complete.
 
4、根据SCN或者时间进行闪回查询
 
SQL> select * from t;
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
SQL> select * from t as of scn 1136165;  ---根据SCN号得到在该SCN号时的数据情况
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
3          3
 
SQL> select * from t as of timestamp to_timestamp('20140313 22:37:48','yyyymmdd hh24:mi:ss'); --得到具体时间点的数据
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
3          3
 
Flashback version query 允许查看相同行在一段时间内所有的版本，记录了数据的历史变化过程
 
Flashback transcation query能够查询事务对表所做的操作，通过UNDO SQL可以取消对事务所做的修改。查询FLASHBACK_TRANSACTION_QUERY这个数据字典表来获取字典事务ID的信息.
 
Flashback table复原一个表到某个时间点，或者某个SCN而不用回复数据文件。闪回表依赖UNDO数据，当表结构改变的时候，不能进行闪回。Flashback drop用户恢复被误删除的表。允许你从当前数据库中恢复一个被drop的对象。在执行drop操作时，现在oracle不是真正删除他，而是将对象自动放入回收站，对于一个对象的删除，其实就是一个简单的重命令操作，并且所在的表空间不变。表上面的约束也在放在回收站里面，在闪回后，索引的名称还是系统默认的，需要手工还原。表上的物化视图日志不会随着表的删除而放入回收站。
 
对闪回表语句不能进行回滚，如何要闪回表，你需要有对表的flashback对象权限或者flashback any table系统权限。row movement对应flash drop没有影响，但是想要使用闪回表来恢复被删除的数据时，就需要开启row movement。flashback drop不会恢复表相关的约束信息
 
flashback table to scn或者to timestamp，如果当前存在索引，闪回到创建索引之前的时间时候，闪回后，系统仍然存在索引。如果当前drop了索引，那闪回到创建索引的时间点时，索引是变成没有了。
 
闪回表的命令如下：
 

 
TO SCN Clause
 
示例如下：SQL> create tablespace tbs_user datafile '/u01/app/oracle/oradata/PROD/disk1/tbs_user.dbf' size 20M autoextend on extent management local;
 
Tablespace created.
 
SQL> create user sec identified by sec default tablespace tbs_user;
 
User created.
 
SQL> grant connect,resource,dba to sec;
 
Grant succeeded.
 
SQL> conn sec/sec
 
Connected.
 
SQL> create table t (a number,b number);
 
Table created.
 
SQL> insert into t values(1,1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1169506
 
SQL> insert into t values(2,2);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select * from t;
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1169526
 
SQL> flashback table t to scn 1169506;  ----闪回表的时候，需要对表执行row movment
 
flashback table t to scn 1169506
 
*
 
ERROR at line 1:
 
ORA-08189: cannot flashback the table because row movement is not enabled
 
SQL> alter table t enable row movement;
 
Table altered.
 
SQL> flashback table t to scn 1169506;
 
Flashback complete.
 
SQL> select * from t;------表闪回到具体的SCN时的情形
 
A          B
 
---------- ----------
 
1          1
 
SQL> flashback table t to scn 1169526;
 
Flashback complete.
 
SQL> select * from t; ---闪回到最后的位置
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
----------------------------------下面是验证索引在flashback table to scn中的情况-----
 
SQL> drop table t;
 
Table dropped.
 
SQL> create table t(a number,b number);
 
Table created.
 
SQL> insert into t values(1,1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1170627
 
SQL> insert into t values(2,2);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> create index idx_t on t(a);
 
Index created.
 
SQL> select dbms_flashback.get_system_change_number from dual; ---该时间点表中存在索引
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1170662
 
SQL> insert into t values(3,3);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1170672
 
SQL> select index_name,status from user_indexes where table_name='T';
 
INDEX_NAME                     STATUS
 
------------------------------ --------
 
IDX_T                          VALID
 
SQL> alter table t enable row movement;
 
Table altered.
 
SQL> flashback table t to scn 1170627;      ----恢复到没有创建索引之前的SCN
 
Flashback complete.
 
SQL> select * from t;
 
A          B
 
---------- ----------
 
1          1
 
SQL> select index_name,status from user_indexes where table_name='T';----此时索引仍然存在
 
INDEX_NAME                     STATUS
 
------------------------------ --------
 
IDX_T                          VALID
 
SQL> flashback table t to scn 1170672;  ---闪回到最后的SCN
 
Flashback complete.
 
SQL> select * from t;
 
A          B
 
---------- ----------
 
1          1
 
2          2
 
3          3
 
SQL> drop index idx_t;----删除索引
 
Index dropped.
 
SQL> flashback table t to scn 1170662;-----闪回到创建索引的SCN ，但是经过闪回后索引已经不再存在了
 
Flashback complete.
 
SQL> select index_name,status from user_indexes where table_name='T';
 
no rows selected
 
SQL>
 
ENABLE | DISABLE TRIGGERS缺省情况下，闪回表时，表上的triggers是不能使用的，可以使用enable triggers来是闪回的同时启用triggers
 
TO BEFORE DROP Clause
 
Using Flashback Drop and Managing the Recycle Bin
 
When you drop a table, the database does not immediately remove the space associated with the table. The database renames the table and places it and any associated objects in a recycle bin, where, in case the table was dropped in error, it can be recovered at a later time. This feature is called Flashback Drop, and the FLASHBACK TABLE statement is used to restore the table. Before discussing the use of the FLASHBACK TABLE statement for this purpose, it is important to understand how the recycle bin works, and how you manage its contents.
 
---当你删除一张表，数据库不是立刻删除表所占的空间，数据库会重命名表并把它和相关的对象放在回收站里面，防止表被误删除之后，能够进行恢复，这个特征就叫做闪回删除，使用
 
flashbackup table继续表的恢复。
 
如果想要开启闪回删除表功能，需在数据库开始回收站功能。
 
SQL> alter system set recyclebin=on ;
 
System altered.
 
SQL> show parameter recyclebin
 
NAME                                 TYPE        VALUE
 
------------------------------------ ----------- ------------------------------
 
recyclebin                           string      ON
 
回收站中的对象命名格式：
 
The renaming convention is as follows:
 
BIN$unique_id$version
 
SQL> select object_name,original_name from recyclebin;
 
OBJECT_NAME                    ORIGINAL_NAME
 
------------------------------ --------------------------------
 
BIN$9JC9w+cttHDgQKjAN/lQpQ==$0 T
 
Disabling the recycle bin does not purge or otherwise affect objects already in the recycle bin.---关闭回收站，不影响原先已经在recyclebin里面的数据。Viewing and Querying Objects in the Recycle BinOracle Database provides two views for obtaining information about objects in the recycle bin:
 
View
 
Description
 
USER_RECYCLEBIN
 
This view can be used by users to see their own dropped objects in the recycle bin. It has a synonym RECYCLEBIN, for ease of use.
 
DBA_RECYCLEBIN
 
This view gives administrators visibility to all dropped objects in the recycle bin
 
删除回收站
 
使用purge命令能够永久的从回收站中删除对象，从回收站删除的对象就不能再用flashback命令恢复了。
 
语法：Purge {table |index }
 
语法：purge tablespace [user ]
 
语法：purge [USER_|DBA_]recyclebin
 
PURGE TABLESPACE  清除指定表空间内的所有回收站对象。存在于其他表空间的互相关联的对象也会被清除。也可以指定USER清除相应用户的对象。--PURGE TABLESPACE example USER oe;
 
PURGE RECYCLEBIN  清除当前用户的所有对象。
 
PURGE DBA_RECYCLEBIN 清除所有对象，需要有足够的系统权限或者SYSDBA的权限。
 
----------------
 
SQL> create table t(a number,b number);
 
Table created.
 
SQL> insert into t values(1,1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> drop table t;
 
Table dropped.
 
SQL> create table t(a number,b number);
 
Table created.
 
SQL> insert into t values(2,2);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> drop table t;
 
Table dropped.
 
SQL> select object_name,droptime from recyclebin;
 
OBJECT_NAME                    DROPTIME
 
------------------------------ -------------------
 
BIN$9JC9w+cwtHDgQKjAN/lQpQ==$0 2014-03-14:22:30:10
 
BIN$9JC9w+cvtHDgQKjAN/lQpQ==$0 2014-03-14:22:31:10
 
SQL> flashback table "BIN$9JC9w+cvtHDgQKjAN/lQpQ==$0" to before drop;-----表恢复完成
 
Flashback complete.
 
SQL> select * from t;
 
A          B
 
---------- ----------
 
1          1
 
SQL>
 
-----如何恢复索引-----
 
SQL> create table t(a number ,b number);
 
Table created.
 
SQL> create index idx_t on t(a);
 
Index created.
 
SQL> select index_name from user_indexes;
 
INDEX_NAME
 
------------------------------
 
IDX_T
 
SQL> select table_name from user_tables;
 
TABLE_NAME
 
------------------------------
 
T
 
SQL> drop table t;
 
Table dropped.
 
SQL> select table_name from user_tables;
 
no rows selected
 
SQL> select index_name from user_indexes;
 
no rows selected
 
SQL> select object_name,original_name,type from recyclebin;----表中存在着表T和T表示的索引IDX_T
 
OBJECT_NAME                    ORIGINAL_NAME
 
------------------------------ --------------------------------
 
TYPE
 
-------------------------
 
BIN$9JC9w+c3tHDgQKjAN/lQpQ==$0 IDX_T
 
INDEX
 
BIN$9JC9w+c4tHDgQKjAN/lQpQ==$0 T
 
TABLE
 
SQL> flashback table t to before drop;
 
Flashback complete.
 
SQL> select object_name,original_name,type from recyclebin; ----闪回之后，回收站中已经没有表和索引了
 
no rows selected
 
SQL> desc t;  ----表T已经恢复
 
Name                                      Null?    Type
 
----------------------------------------- -------- ----------------------------
 
A                                                  NUMBER
 
B                                                  NUMBER
 
SQL> select index_name from user_indexes; ---索引也已经恢复，但是索引的名称还是原来在回收站里面的名称
 
INDEX_NAME
 
------------------------------
 
BIN$9JC9w+c3tHDgQKjAN/lQpQ==$0
 
SQL> alter index "BIN$9JC9w+c3tHDgQKjAN/lQpQ==$0" rename to idx_t; ---手工修改索引名称
 
Index altered.
 
SQL> select index_name from user_indexes;
 
INDEX_NAME
 
------------------------------
 
IDX_T
 
SQL>
 
Flashback Database命令是为了加快原本很慢的时间点数据库恢复(point in time database recovery)过程。闪回可以取得完整的数据库恢复和使用归档日志的前滚，主要目的是加快从“意外状态“中恢复。闪回数据库基于闪回日志flashback log，闪回日志包含已修改数据块的”前影像“，可用于将数据库恢复到该时间点之前的状态。闪回数据库允许复原整个数据库到具体的时间点，从而撤销该时间点以来的所有数据库的变化
 
用户误删除表中数据、
 
删除表、
 
truncate
 
表、
 
索引、
 
触发器，
 
表空间等。
 
Dba
 
误操作等。简而言之，所有操作都可以闪回。
 
Flashback Database enables you to rewind the database to a previous point in time without restoring backup copies of the datafiles.--闪回数据库能够使你在不恢复数据文件备份的情况下使数据库倒回到先去的某个时间点。
 
You can flash back a database from both RMAN and SQL*Plus with a single command instead of using a complex procedure.--你可以通过RMAN或者SQLPLUS来闪回数据库，替代使用复杂的过程。
 
使用数据库闪回可撤销导致逻辑数据损坏的变更，如果是介质丢失或者物理损坏，则必须使用传统的恢复方法进行数据库的恢复。闪回数据库不需要恢复数据文件，以此恢复数据库的数据与所需要恢复的数据条目成正比，和数据库的大小无关。闪回数据库头通过闪回日志来进行数据恢复，数据库会定期将数据快的前影像记录在闪回日志里面Requirements for Enabling Flashback DatabaseThe requirements for enabling Flashback Database are:
 
Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation.
 
You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area.
 
For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM.
 
---数据库必须在归档模式下，因为在闪回数据库过程中需要有归档日志文件
 
--必须有闪回恢复区，闪回日志只能存放在flash recovery area里面
 
--在rac模式下，闪回恢复区必须存在在一个集群文件系统
 
首先开启数据库归档模式
 
SQL> startup mount;
 
ORACLE instance started.
 
Total System Global Area  314572800 bytes
 
Fixed Size                  1219184 bytes
 
Variable Size              83887504 bytes
 
Database Buffers          226492416 bytes
 
Redo Buffers                2973696 bytes
 
Database mounted.
 
SQL> alter database archivelog;
 
Database altered.
 
SQL> archive log list
 
Database log mode              Archive Mode  --归档模式
 
Automatic archival             Enabled
 
Archive destination            USE_DB_RECOVERY_FILE_DEST
 
Oldest online log sequence     29--最老的在线日志
 
Next log sequence to archive   31--将要归档的日志
 
Current log sequence           31 ---当前日志
 
SQL> alter database open;
 
Database altered.
 
SQL> select SEQUENCE#,STATUS from v$log;
 
SEQUENCE# STATUS
 
---------- ----------------
 
31 CURRENT---当前日志
 
29 INACTIVE
 
30 INACTIVE
 
SQL> alter system set log_archive_dest_1='location=/u01/app/oracle/arch' scope=spfile;  --修改归档日志的目录
 
System altered.
 
SQL> show parameter log_archive_format
 
NAME                                 TYPE        VALUE
 
------------------------------------ ----------- ------------------------------
 
log_archive_format                   string      %t_%s_%r.dbf
 
%s:日志序列号:
 
%t:重做线程编号.
 
%d:数据库ID号
 
%r RESETLOGS的ID值.
 
设置闪回数据库参数
 
设置数据库闪回的三个参数：
 
db_recovery_file_dest_size  闪回恢复区大小
 
db_recovery_file_dest  闪回恢复区路径，该参数可以任意指定，闪回日志记录了数据库的前影像，该日志不会进行归档，一但停用数据库的闪回功能，该目录下的日志会
 
自动清除
 
db_flashback_retention_target  保留恢复最近多长时间的数据，单位为分钟。
 
SQL> alter system set db_recovery_file_dest_size=5G;
 
System altered.
 
SQL> alter system set db_recovery_file_dest='/home/oracle/flash';
 
System altered.
 
SQL> alter system set db_flashback_retention_target=2440;  --分钟  2天，系统默认是1天
 
System altered.
 
开启数据库闪回功能
 
SQL> startup mount
 
ORACLE instance started.
 
Total System Global Area  314572800 bytes
 
Fixed Size                  1219184 bytes
 
Variable Size              75498896 bytes
 
Database Buffers          234881024 bytes
 
Redo Buffers                2973696 bytes
 
Database mounted.
 
SQL> alter database flashback on;
 
Database altered.
 
SQL> alter database open;
 
Database altered.
 
SQL> select flashback_on from v$database;
 
FLASHBACK_ON
 
------------------
 
YES
 
闪回数据库语法：
 

 
v$flashback_database_stat--用于监视闪回数据库日志中记录闪回数据的开销，包含24小时的信息，每行代表一个小时的时间间隔，可以确定数据生成的变化，
 
FLASHBACK_DATA和REDO_DATA分别表示时间间隔内写入的闪回字节数和重做日志字节数
 
v$flashback_database_log---记录闪回日志信息，包括最早可以回复的SCN，闪回日志的大小
 
v$flash_recovery_area_usage---监控闪回恢复区的使用情况
 
基于SCN的闪回，有两只方式 SQL和RMAN
 
---------------------
 
SQL> insert into t values(1,1);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
-----------------------
 
1242503
 
SQL> insert into t values(2,2);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
-----------------------
 
1242520
 
SQL> insert into t values(3,3);
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> select dbms_flashback.get_system_change_number from dual;
 
GET_SYSTEM_CHANGE_NUMBER
 
------------------------
 
1242533
 
SQL> shutdown immediate
 
Database closed.
 
Database dismounted.
 
ORACLE instance shut down.
 
SQL> startup mount;
 
ORACLE instance started.
 
Total System Global Area  314572800 bytes
 
Fixed Size                  1219184 bytes
 
Variable Size              75498896 bytes
 
Database Buffers          234881024 bytes
 
Redo Buffers                2973696 bytes
 
Database mounted.
 
SQL> flashback database to scn 1242503;----闪回到第一次commit的时候
 
Flashback complete.
 
SQL> alter database open resetlogs;
 
Database altered.
 
SQL> select * from t;  ---闪回数据库测试正常
 
A          B
 
---------- ----------
 
1          1
 
SQL>
 
---------------------------------------
 
TO timestamp---例子
 
flashback database to timestamp to_date('2011-07-12 10:20:59','yyyy-mm-dd hh24:mi:ss');
 
小结：
 
oracle10g数据库提供了闪回功能，无论对开发人员，还是DBA人员提供了便捷的处理逻辑数据丢失的处理方法，非常实用。
 
jiangkch
 
20140319
 
-----------------------------------------

 
闪回原理
 
既然binlog以event形式记录了所有的变更信息，那么我们把需要回滚的event，从后往前回滚回去即可。
 
对于单个event的回滚，我们以表test.user来演示原理
 
mysql> show create table test.user \G
 
******************1. row************************
 
Table: user
 
Create Table: CREATE TABLI ‘user’ (‘id’ int(11) NOT NULL AUTO_INCREMENT,’name’ varchar(10) DEFAULT NULl PRIMARY KEY (‘id’) ENGINE=InnoDB AUTO INCREMENT=6 DEFAULT CHARSET=utf8
 
对于delete操作,我们从binlog提取出delete信息，反向生成的回滚语句是Insert。(注:为了方便解释,我们用binlog2sql将原始 binlog转化成了可读SQL)
 
原始：DELETE FROM test, user where id=1 AND ‘name’=’小赵’;
 
回滚：INSERT INTO test.user(id,name) VALUES(1,"小赵");
 
对于insert操作,反向生成delete回滚语句。
 
原始：INSERT INTo test.user(‘id’,’name’) values (2,’小钱’);
 
回滚：DELETE from test.user where id=2, name=’小钱’;
 
对于update操作,回滚sql应该交换SET和WHEREI的值，反向生成update语句；
 
原始：UPDATE test.user SET id=3,name=’小李’where id=3 AND name=’小孙’;
 
回滚：UPDATE test.user SET id=3,name=’小孙’’where id=3 AND name=’小李’;
 
闪回实战
 
真实的闪回场景中，最关键的是能快速筛选出真正需要回滚的SQL。
 
我们使用开源工具binlog2sql来进行实战演练。binlog2sql由美团点评DBA团队(上海)出品，多次在线上环境做快速回滚。
 
首先我们安装binlog2sql：
 
# git clone https://github.co/danfengcao/binlog2sql.git&&cdbinlos
 
# pip install -r requirements.txt
 
背景:小明在11:44时误删了test库user表大批的数据,需要紧急回滚。
 
test库user表原有数据
 
mysql> select*from user;
 
+-----+------+--------------------------+
 
| id | name| addtime     |
 
+-----+------+--------------------------+
 
|1  |小赵|2013-11-11 00:04:33|
 
|2  |小钱|2014-11-11 00:04:48|
 
|3  |小孙|2016-11-11 20:25:00 |
 
|4  |小李|2013-11-11 09:00:00|
 
·······
 
+-----+------+--------------------------+
 
16384 rows in set (0. 04 sec)
 
11:44时,user表大批数据被误刪除。与此同时,正常业务数据是在继续写入的
 
mysql>delete from user where addtime>'2014-01-01；
 
Query OK, 16128 rows affected (0. 18 sec)
 
mysql>seLect count(*)from user;
 
+-------------+
 
| count(*) |
 
+-------------+
 
| 261    |
 
+-------------+
 
恢复数据步骤：
 
登录mysql，查看目前的binlog文件
 
mysql> seLect count(*) from user;
 
+-------------------------+--------------+
 
| Log_name      | File_size  |
 
+-------------------------+--------------+
 
| mysql-bin.000053 |168652863|
 
| mysql-bin.000054 | 504549   |
 
+-------------------------+---------------+
 
最新的binlog文件是mysql-bin.000054。我们的目标是筛选出需要回滚的SQL，由于误操作人只知道大致的误操作时间，我们首先根据时间做一次过滤。只需要解析test库user表。(注：如果有多个sql误操作，则生成的binlog可能分布在多个文件，需解析多个文件)
 
#python binlog2sql/binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p’admin’
 
raw.sql输出：
 
delete from test.user where ‘addtime’=’2014-11-11 00:45:15’ and id=456 and name=’照照’;
 
delete from test.user where ‘addtime’=’2014-11-12 00:45:15’ and id=486 and name=’溜溜’;
 
······
 
delete from test.user where ‘addtime’=’2014-11-18 00:45:15’ and id=496 and name=’海海’;
 
insert into ‘test’.’user’(‘addtime’,’id’,’name’) values (2012-12-14 00.45.15,459,’可可’)
 
根据位置信息，我们确定了误操作sql来自同一个事务，准确位置在257427-504272之间(binlog2sql对于同一个事务会输出同样的start position)。再根据位置过滤，使用-B选项生成回滚sql，检查回滚sql是否正确。(注：真实场景下，生成的回滚SQL经常会需要进一步筛选。结合grep、编辑器等)
 
#python binlog2sql/binlog2sql.py -h127.0.0.1 -P3306 -uadmin -p’admin’
 
rollbach.sql输出：
 
insert into ‘test’.’user’(‘addtime’,’id’,’name’) values (2016-12-14 00.45.15,456,’照照’)
 
insert into ‘test’.’user’(‘addtime’,’id’,’name’) values (2016-12-15 00.45.15,486,’溜溜’)
 
······
 
insert into ‘test’.’user’(‘addtime’,’id’,’name’) values (2016-12-16 00.45.15,459,’可可’)
 
# wc -l /tmp/rollback.sql
 
16128  /tmp/rollback.sql
 
与业务方确认回滚sql没问题，执行回滚语句。登录mysql，确认回滚成功。
 
# mysql -h127.0.0.1 -P3306 -uadmin -p’admin’< /tmp/rollback.sql
 
mysql> select count(*) from user;
 
+----------------+
 
| count(*)   |
 
+----------------+
 
| 16389    |
 
+----------------+
 
TIPS
 
闪回的关键是快速筛选出真正需要回滚的SQL。
 
先根据库、表、时间做一次过滤，再根据位置做更准确的过滤。
 
由于数据一直在写入，要确保回滚sql中不包含其他数据。可根据是否是同一事务、误操作行数、字段值的特征等等来帮助判断。
 
执行回滚sql时如有报错，需要查实具体原因，一般是因为对应的数据已发生变化。由于是严格的行模式，只要有唯一键(包括主键)存在，就只会报某条数据不存在的错，不必担心会更新不该操作的数据。
 
如果待回滚的表与其他表有关联，要与开发说明回滚和不回滚各自的副作用，再确定方案。
 
回滚后数据变化，可能对用户和线上应用造成困惑(类似幻读)。
 
再重复下最重要的两点：筛选出正确SQL！沟通清楚！
 
闪回工具
 
MySQL闪回特性最早由阿里彭立勋开发，彭在2012年给官方提交了一个patch，并对闪回设计思路做了说明。彭之后，又有多位人员针对不同mysql版本不同语言开发了闪回工具，原理用的都是彭的思路。
 
闪回工具按实现方式分成了三类。
 
第一类是以patch形式集成到官方工具mysqlbinlog中。以彭提交的patch为代表。
 
缺点：
 
兼容性差、项目活跃度不高。由于binlog格式的变动，如果闪回工具作者不及时对补丁升级，则闪回工具将无法使用。目前已有多位人员分别针对mysql5.5，5.6，5.7开发了patch，部分项目代码公开，但总体上活跃度都不高。
 
难以添加新功能，实战效果欠佳。在实战中，经常会遇到现有patch不满足需求的情况，比如要加个表过滤，很简单的一个需求，代码改动也不会大，但对大部分DBA来说，改mysql源码还是很困难的事。
 
安装稍显麻烦。需要对mysql源码打补丁再编译生成。
 
优点：
 
上手成本低。mysqlbinlog原有的选项都能直接利用，只是多加了一个闪回选项。闪回特性未来有可能被官方收录。
 
支持离线解析。
 
第二类是独立工具，通过伪装成slave拉取binlog来进行处理。以binlog2sql为代表。
 
缺点：
 
必须开启MySQL server。
 
优点：
 
兼容性好。伪装成slave拉binlog这项技术在业界应用的非常广泛，多个开发语言都有这样的活跃项目，MySQL版本的兼容性由这些项目搞定，闪回工具的兼容问题不再突出。
 
添加新功能的难度小。更容易被改造成DBA自己喜欢的形式。更适合实战。
 
安装和使用简单。
 
第三类是简单脚本。先用mysqlbinlog解析出文本格式的binlog,再根据回滚原理用正则进行匹配并替换。
 
缺点：
 
通用性不好。
 
可靠性不好。
 
优点：
 
脚本写起来方便，往往能快速搞定某个特定问题。
 
安装和使用简单。
 
支持离线解析。
 
就目前的闪回工具而言，线上环境的闪回，笔者建议使用binlog2sql，离线解析使用mysqlbinlog。
 
MySQL闪回工具之binlog2sql
 
用途：
 
数据回滚；；主从切换后数据不一致的修复；；从binlog生成标准SQL，带来的衍生功能；；
 
使用python-mysql-replication作为实时解析MySQL binlog来获取各个event
 
python-mysql-replication实现了MySQL复制协议，客户端伪装成slave来获取主的binlog和event，使用它可以通过读取binlog来实现一些完成实时计算，而无须先存储再计算。但这也是一个缺点，如果没有前提，binlog2sql就无法完成工作，而且如果在高并发的环境中要进行解析binlog，也就相当于多了一个同步线程在主上读取数据，加大了主的负担。
 
在生产使用之前，一定在测试通过之后使用，确保没有数据错误。
 
关于DDL的flashback
 
这里所述的flashback仅针对DML语句的快速回滚。但如果误操作是DDL的话，是无法利用binlog做快速回滚的，因为即使在row模式下，binlog对于DDL操作也不会记录每行数据的变化。要实现DDL快速回滚，必须修改MySQL源码，使得在执行DDL前先备份老数据。
 
在flashback模式下，一次性处理的binlog不易过大，不能超过内存大小。
 
目前有多个mysql定制版本实现了DDL闪回特性，阿里林晓斌团队提交了patch(修改mysql server的源码)给MySQL官方，MariaDB预计在不久后加入包含DDL的flashback特性。DDL闪回的副作用是会增加额外存储而且低频。