Maclean’s Oracle Database Tech Blog Archives

本文地址：https://www.askmac.cn/archives/mysql-backup_recovery_knowledge.html     第11章 备份和恢复   章节概述 本章介绍了MySQL数据备份和恢复。你将学习并了解： 备份的类型 进行二进制备份和文本备份 备份中日志和状态文件的角色作用 使用一个复制从库（replication slave）来进行备份 进行数据恢复 倒入数据文件   11.1 备份概述 MySQL数据库备份一般用于应对可能的系统崩溃或硬件故障而导致的数据损失或讹误问题。备份同样对于用户误操作，如误删数据库或表等恢复有帮助。也有时候备份被用于将数据库拷贝或移动到另一个服务器中，如当你需要进行MySQL安装迁移，或建立一个复制从库时。   备份可以是对数据文件的直接拷贝，或是通过设计程序来完成同样的备份目的。这些程序包括mysqldump，mysqlhotcopy和InnoDB Hot Backup。   对于数据库运维，备份总是必要的，不过备份仅仅是在数据受损后所需进行数据恢复的组件之一。其它的你还需要二进制日志(binary log)文件，它包含了数据修改的记录。进行数据库恢复时，你使用备份将数据库恢复到备份时的状态，然后重新执行binary log中包含的语句来应用备份后的数据修改。   这里列出了在进行备份时需要记住的一些原则： 制作一般备份。 启用binary log，这样你在进行备份后，对数据修改的记录将会被保存在日志文件中。 在备份后，使用flush命令，使得服务端从一个新的binary log文件开始，这个日志文件对应了备份的时间（也就是说，将此备份后的日志看作是一个“检查点”，从这个时间后开始的日志记录是备份之后新的数据修改）。 将数据文件目录和你的备份放置在不同的物理设备中，这样一旦某个设备出现故障，不会造成同时被影响的后果。 将你的备份存在在通常合理的文件系统位置中，这样一旦需要就可以从这些位置上找到备份进行恢复。

本文固定链接：https://www.askmac.cn/archives/testing-hadoop-programs.html 测试Hadoop程序   本章介绍了如何在你本地集成开发环境（ IDE ）中对Hadoop程序进行单元测试。虽然自早期的Hadoop以来，Hadoop程序单元测试已经取得很大进展，但因为Hadoop的组件，如Mappers 和 Reducers，是在分布式环境中运行，它仍然是具有挑战性的。 我们讨论了MapReduce单元测试API，称为MRUnit，这使我们能够独立地对Mapper 和 Reducer类进行单元测试。讨论完MRUnit的限制，我们将探讨处理这些限制的LocalJobRunner类。本章结尾将着探讨MiniMRCluster类，这使我们能够在内存中运行一个完整的MapReduce框架，使其在整个MapReduce框架环境下，适合于MapReduce组件的综合测试。   回顾Word Counter 表8-1是你在第3章所看到的word counter的Reducer

毫无疑问，MySQL是最为流行的开源数据库系统，已经广泛的应用于各大互联网公司。目前，大量的传统金融客户也已经逐渐在其生产环境使用MySQL数据库，在互联网+的时代MySQL扮演着举足轻重的角色。本次大会将为MySQL技术爱好者带来最具分享意义的主题，包括MySQL数据库新特性、高可用容灾安全、数据库云架构、行业客户最佳应用实践。本次数据库会议邀请国内顶级MySQL数据库专家分享，旨在打造成一个最有态度的MySQL数据库大会。   SHOUG(上海Oracle用户组)和IMG(Inside MySQL Group)合作来推广本次会议，希望用户组之间的合作能够给大家更多学习的机会。   IMG 2016 MySQL技术嘉年华官方网址：http://www.innomysql.net/img2016/            

Leading Chinese database services company to offer common data platform for Information Lifecycle Management (ILM) and advanced analytics based on Apache Hadoop. 2016 — Santa Clara, Calif. — Solix Technologies, Inc.,  Solix Technologies, the leading provider of Information Lifecycle Management (ILM) solutions for Apache Hadoop, announced today that Chinese database service company Parnassus Data has…

本文地址：https://www.askmac.cn/archives/mysql-innodb-myisam-recoveryinfo.html   10.4 修复InnoDB表 在之前的章节中，我们已经了解了可以通过执行CHECK TABLE语句或使用客户端工具来发出此语句，来对InnoDB表进行检查。不过，如果InnoDB表存在问题，那么你并不能使用REPAIR TABLE来对表进行维修，因为这个命令仅对MyISAM可用。   如果检查不InnoDB表有问题，那么你应该使用mysqldump来将表恢复到一个一致性状态，即删除表，并通过dump文件进行重建：     shell> mysqldump db_name table_name > dump_file shell> mysql db_name < dump_file   在遇到MySQL服务端奔溃或数据库运行的主机奔溃后，一些InnoDB表可能会需要进行修复。正常情况下，简单的进行服务端重启就行了，因为InnoDB存储引擎在启动时会进行自动恢复作业。少数情况下，可能由于InnoDB自动恢复失败而导致服务端无法启动。如果碰到这样的情况，请按以下步骤进行操作： 使用带有 –innodb-force-recovery（值范围为1~6）的命令项来重启服务端。这个值用于提高警告屏蔽级别以避免启动崩溃，对于被恢复的表，允许更高不一致容忍度。较好是值使用从4开始。 当你启动服务端并使用 –innodb-force-recovery设为一个非0值，InnoDB会将表空间作为只读处理（从7.3版本开始，值为4或更大时，将使得InnoDB置于只读模式）。之后，你应该使用mysqldump工具来倒出InnoDB表数据，并在导出后，在此命令项有效的情况下将InnoDB表删除。然后在不使用 –innodb-force-recovery项的情况下重启服务端。当服务端起来后，再从导出的dump文件来恢复InnoDB表。 如果之前的步骤都失败了，那就有必要从之前的备份来恢复InnoDB表了。

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]     SQL Server中数据库置疑的几个原因 操作系统找不到对应的数据库文件MDF/NDF 无法打开或访问日志文件LDF 由于异常重启导致损坏了MDF/NDF/LDF文件   数据库处于置疑状态中可能出现的一些报错： Error: 9003, Severity: 20, State: 9 – The log scan number (178956:14:2) passed to log scan in database is not valid. Error: 3414, Severity: 21, State: 1 – An error occurred during recovery, preventing the database (database…

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   SQL 错误945 ： Database cannot be opened due to inaccessible files or insufficient memory or disk space  ， 是常见的SQL数据库故障之一。可以尝试调式环境或使用SQL恢复工具DBRECOVER FOR SQL SERVER来恢复数据。   什么是SQL Server 945错误？   SQL Server错误945发生在当数据库处于isshutdown状态或尝试附加/卸载数据库MDF文件时必要的系统工作未完成从而导致恢复操作无法将数据库置于在线状态。其可能发生在以下的情况下： 因为memory-optimized内存优化表而导致大量磁盘空间被消耗 因为丢失一些文件或页导致SQL数据库修复操作失败 使用了本来就损坏的备份文件 不当的数据库关闭操作 数据库文件被病毒攻击   以下是一些针对SQL Server 945错误的解决方法   解决方案 根据用户经验，以下是一些行之有效的解决MSG 945错误的方案：   扩充硬件空间 观察windows下的所有盘符，确保每个盘符下至少有5GB的剩余空间。也可以检查Windows事件日志看看有无磁盘空间相关报错。…

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   8646 Unable to find index entry in index ID %d, of table %d, in database ‘%.*ls’. The indicated index is corrupt or there is a problem with the current update plan. Run DBCC CHECKDB or DBCC CHECKTABLE. If the problem persists, contact product support.  …

SELECT message_id AS Error, severity AS Severity, [Event Logged] = CASE is_event_logged WHEN 0 THEN ‘No’ ELSE ‘Yes’ END, text AS [Description] FROM sys.messages WHERE language_id = ORDER BY message_id    

  如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   SQL Server数据库的损坏处理相比于oracle数据库而言是简单一些的，这个简单主要体现在微软或者说sybase提供了对损坏/置疑数据库的紧急EMERGENCY模式，以便用户能够从有问题而无备份的数据库中拯救出数据。而oracle则官方不提供这种方案。但对于连数据文件头都损失的场景在SQL Server的紧急模式也没法发挥作用，这是因为启动块等重要数据都在MDF文件头部。所以实际上即便不备份整个MDF文件，但备份其头部也是有意义的。这和我们在Oracle ASM中定期备份ASM disk header是类似的。但这种想法还是过于理想，没有备份就是没有备份计划或者备份计划不当的结果。 所以任何其他RDBMS(MYSQL Oracle)都会出现的问题，在SQL Server中也无从避免。数据文件头丢失也是类似的，与普通的数据块丢失不同。普通的数据块丢失可能只影响少数表或索引，用户也可以割舍这少部分数据。而数据文件头的丢失将导致数据库彻底不可用，这是有本质区别的。 4> alter database testn1 set emergency; 5> go Msg 5172, Level 16, State 15, Server DESKTOP-L414PA5\SQLEXPRESS, Line 4 The header for file ‘E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\testn1.mdf’ is not a valid database file header. The PageAudit…