MSSQL教程之InnoDB 中文参考手册 --- 6 备份和恢复...

提供用于管理、检查、优化数据库操作的管理工具。备份|参考|参考手册|恢复|数据|数据库|中文InnoDB中文参考手册---犬犬(心帆)翻译6备份和恢复InnoDB数据库
平安的数据库办理就是利用正轨的数据备份。

InnoDBHotBackup是一个在线备份工具，你能够在InnoDB数据库运转时利用它来完成在线备份。InnoDBHotBackup不必要你封闭你的服务器也不必要加任何锁或影响别的一般的数据操纵。InnoDBHotBackup是一个非收费的附加工具，它的用度为每MySQL服务器每一年400欧元。扫瞄网页InnoDBHotBackuphomepage可取得更多的信息和程序屏幕截图。

假如你能够封闭你的MySQL服务，那末能够经由过程上面几个步骤举行数据库的“二进制”备份：
封闭MySQL数据库服务，并断定在封闭时没有产生任何毛病将你的一切数据文件复制到一个平安的中央将一切的InnoDB日记文件复制到一个平安的中央将my.cnf设置文件复制到一个平安的中央将一切的InnoDB表.frm文件复制到一个平安的中央
在必要高功能的数据库服务站点上，能够经由过程MySQL的复制特征来坚持数据库的一个正本，MySQL的复制特征一样合用于InnoDB表范例。

除下面形貌的二进制备份体例以外，最好按期地利用mysqldump转储数据表。缘故原由是二进制文件大概会在你未注重时而被损坏，而表转储(dump)文件是以文本文件体例保留的，它与二进制文件比拟更复杂、有更好的的可读性。由于转储文件更复杂以是更简单发明表破坏，主要数据损环的大概性很小。

一个好的主张就是在对数据库做二进制备份的同时也做一个转储(dump)备份。为了失掉分歧的数据快照，必需封闭一切客户真个毗连。然后就能够举行二进制备份，如许你就有了数据分歧的两种格局的备份。

如了完成经由过程下面所述的二进制备份办法将InnoDB数据库恢复到以后形态，必需翻开MySQL的二进制日记(binlogging)开关。如许你就能够二进制日记与备份数据共同完成分工夫点的恢复：
mysqlbinlogyourhostname-bin.123|mysql

　

为了恢复一个溃散了的MySQL服务历程，你所能做的独一一件事就是从头启动。InnoDB将主动地反省日记并完成数据库的前滚(roll-forward)到以后形态。同时，InnoDB将主动回滚溃散前未提交的事件。在恢复过程当中，mysqld将显现以下所示的提醒：

heikki@donna:~/mysql-3.23.48/sql>mysqld02020423:08:31InnoDB:Databasewasnotshutdownnormally.InnoDB:Startingrecoveryfromlogfiles...InnoDB:StartinglogscanbasedoncheckpointatInnoDB:logsequencenumber0177573790InnoDB:Doingrecovery:scanneduptologsequencenumber0177638912InnoDB:Doingrecovery:scanneduptologsequencenumber0177704448InnoDB:Doingrecovery:scanneduptologsequencenumber0177769984InnoDB:Doingrecovery:scanneduptologsequencenumber0177835520InnoDB:Doingrecovery:scanneduptologsequencenumber0177901056InnoDB:Doingrecovery:scanneduptologsequencenumber0177966592InnoDB:Doingrecovery:scanneduptologsequencenumber0178032128InnoDB:Doingrecovery:scanneduptologsequencenumber0178097664InnoDB:Doingrecovery:scanneduptologsequencenumber0178163200InnoDB:Doingrecovery:scanneduptologsequencenumber0178228736InnoDB:Afterthisprintsalineforevery10thscansweep:InnoDB:Doingrecovery:scanneduptologsequencenumber0178884096...InnoDB:Doingrecovery:scanneduptologsequencenumber0193302016InnoDB:Doingrecovery:scanneduptologsequencenumber0193957376InnoDB:Doingrecovery:scanneduptologsequencenumber019461273602020423:08:40InnoDB:Startinganapplybatchoflogrecordstothedatabase...InnoDB:Progressinpercents:0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899InnoDB:ApplybatchcompletedInnoDB:Doingrecovery:scanneduptologsequencenumber0195268096InnoDB:Doingrecovery:scanneduptologsequencenumber0195923456...InnoDB:Doingrecovery:scanneduptologsequencenumber0203132416InnoDB:Doingrecovery:scanneduptologsequencenumber0203787776InnoDB:Doingrecovery:scanneduptologsequencenumber0204443136InnoDB:5uncommittedtransaction(s)whichmustberolledbackInnoDB:Trxidcounteris0129792InnoDB:StartingrollbackofuncommittedtransactionsInnoDB:Rollingbacktrxwithid0129400InnoDB:Rollingbackoftrxid0129400completedInnoDB:Rollingbacktrxwithid0129217InnoDB:Rollingbackoftrxid0129217completedInnoDB:Rollingbacktrxwithid0129098InnoDB:Rollingbackoftrxid0129098completedInnoDB:Rollingbacktrxwithid0128743InnoDB:Rollingbackoftrxid0128743completedInnoDB:Rollingbacktrxwithid0127939InnoDB:Rollingbackoftrxid0127939completedInnoDB:Rollbackofuncommittedtransactionscompleted02020423:08:51InnoDB:Startinganapplybatchoflogrecordstothedatabase...InnoDB:Progressinpercents:0123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899InnoDB:ApplybatchcompletedInnoDB:LastMySQLbinlogfileoffset040418561,filename./donna-bin.00102020423:08:53InnoDB:Flushingmodifiedpagesfromthebufferpool...02020423:09:03InnoDB:Startedmysqld:readyforconnections

假如数据库遭到破坏或磁盘失利，则不能不从一个备份文件恢复。在破坏的情形下，起首能够恢复一个未破坏的备份文件。然后按照MySQL手册提醒从一样平常的日记文件中恢单数据。

在某些数据库破坏的情形下，大概经由过程转储(dump)、打消(drop)和从头创建一个或多个破坏的表就充足了。不幸经由过程CHECKTABLESQL命令反省一个受损的表，固然CHECKTABLE其实不能发明一切的破坏范例。你大概利用innodb_tablespace_monitor来反省数据文件时的文件空间办理的完全性。

在某些情形下，数据库页面显现破坏，而实践上是因为操纵体系的文件高速缓冲破坏，而磁盘上的数据文件仍是好的。这时候最好先重起你的体系。这大概办理数据库页面毛病。
6.1强迫(Forcing)恢复
假如呈现数据库页面破坏，能够经由过程SELECTINTOOUTFILE从数据库直达储出表数据，一般年夜部分的数据并未受破坏。可是这些破坏大概引发SELECT*FROMtable或InnoDB背景操纵溃散或中止(assert)，乃至是InnoDB的前滚(roll-forward)恢复溃散。从InnoDBversion3.23.44入手下手，在my.cnf中有个设置选项能够强迫InnoDB启动，和避免背景操纵的运转，因此你能够转储数据。比方，你能够my.cnf在中到场以下设置：
set-variable=innodb_force_recovery=4

　

innodb_force_recovery取代选择将鄙人面列出。这个参数不克不及用于数据库的别的方面！当设置值年夜于0时，作为平安标准，InnoDB克制用户利用INSERT,UPDATE,或DELETE。

从3.23.53和4.0.4入手下手，即便强迫恢复被利用你也能够利用DROP或CREATE一个表。假如你断定表如引发回滚溃散，你能够移除(drop)它。你也能够经由过程这个中断一个因导进大批数据或ALTERTABLE而引发的掉控(runaway)回滚。你能够杀逝世mysqld历程，并利用my.cnf设置项innodb_force_recovery=3不利用回滚。然后就能够DROP谁人引发掉控(runaway)回滚的表。

上面较年夜的数意味着包括一切较低数所对就的平安提防。为了可以转储表设置最少为4，这是绝对平安的，仅仅只要一些破坏的页面数据失落掉。Option6ismoredramatic,becausedatabasepagesareleftinanobsoletestate,whichinturnmayintroducemorecorruptionintoB-treesandotherdatabasestructures.1(SRV_FORCE_IGNORE_CORRUPT)即便发明一个毛病也启动服务；试着利用SELECT*FROMtable跳过破坏的索引纪录和页面，这将匡助转储表。2(SRV_FORCE_NO_BACKGROUND)preventthemainthreadfromrunning:假如在清算过程当中将产生溃散，这将防备它。3(SRV_FORCE_NO_TRX_UNDO)恢复时不运转事件回滚。4(SRV_FORCE_NO_IBUF_MERGE)避免拔出缓冲区的合并操纵：假如他们将引发溃散，最好不要操纵他们；不要思索表统计(tablestatistics)。5(SRV_FORCE_NO_UNDO_LOG_SCAN)当启动数据库时不打消日记(undologs)：InnoDB将未完成的事件已提交。6(SRV_FORCE_NO_LOG_REDO)donotdothelogroll-forwardinconnectionwithrecovery.
　
6.2反省点(Checkpoints)
InnoDB经由过程挪用一个含混的反省点来完成反省点机制。InnoDB以很小的批量从缓冲池中革新修正了的数据库页面。这就不必要在一个批量中革新全部缓冲池，因这个假话大将大概中断用户SQL语句运转历程一段工夫。

IncrashrecoveryInnoDB在溃散修复时会反省纪录在日记文件中的反省点标签。它晓得，在标签前一切对数据库的修正已被纪录到数据库的磁盘镜像中。然后InnoDB扫描日记文件中反省点前面的日记并将修正记进数据库。

InnoDB以一个环形体例纪录日记文件。一切使缓冲池中的数据库页面与磁盘镜像不不异已提交了的修正必需纪录在日记文件中，以防InnoDB必要恢复。这就意味着InnoDB以环形体例从头启用一个日记文件，它必需断定将被从头利用的日记文件中的操纵日记了局已被磁盘镜像文件包括。用另外一句话来讲就是，InnoDB必需经常地创建反省点并将修正了的数据库页面更新到磁盘中。

下面所述要以注释为何将日记文件设置和年夜一点能够削减因创建反省点所用的磁盘I/O。这就能够了解设置日记文件的总尺寸与缓冲池一样年夜或更年夜。年夜的日记文件的弱点就是当举行溃散修复时将必要很长的工夫，由于有更多的操纵日记必要更新到数据库中。
闪回的目的是要让数据库在commit之后，还能恢复到之前的某个状态，整库或指定的表。

你可以简单地认为适合的就是好，不适合就是不好。

一个是把SQL语句写到客户端,可以使用DataSet进行加工;

如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。

where子句的作用是在对查询结果进行分组前，将不符合where条件的行去掉，即在分组之前过滤数据，条件中不能包含聚组函数，使用where条件显示特定的行。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！

发几份SQL课件，以飨阅者

你可以简单地认为适合的就是好，不适合就是不好。