修复数据库的基本步骤(补充)

合集下载

【嘉为IT培训】Exchange 2010数据库损坏后的修复步骤

【嘉为IT培训】Exchange 2010数据库损坏后的修复步骤

Exchange 2010数据库损坏后的修复步骤刘凯:项目经理微软Windows Server System技术专家,网络安全专家,微软企业护航金牌技术专家;MCSE、MCT、MCITP、VCP,现为嘉为企业服务项目经理和微软技术服务资深顾问。

摘要:Exchange数据库作为承载用户邮箱的核心组件,其重要性不言而喻。

数据库一旦卸载,其承载的所有邮箱将无法工作,通常引起卸载的原因有很多种,此次我们所要探讨的是数据库损坏这种极端情况。

可能你会说,有备份做保证,损坏又何妨。

但是,你必然不能忽视一个问题,即还原后的数据库与原数据库存在一定的差异。

因此,我们不推荐数据库损坏后第一时间还原。

如果故障发生在非工作时间,比如晚上或周末,建议优先尝试数据库的修复。

正文:笔者最近就遭遇了一起数据库损坏的故障。

为此,将处理的思路分享给大家。

1. 事件描述磁盘逻辑错误(通过系统NTFS日志可以分析)导致2个数据库无法装入,影响200多用户;在此故障发生之前因为管理员疏忽,数据库的副本状态一直不正常,所以无法在故障发生时激活副本;2. 处理思路通常解决这种问题,我们需要做以下操作:1)检查数据库的状态:eseutil.exe /mh “数据库EDB文件全路径”Eseutil /M 文件转储模式/zh-cn/library/aa997795(v=exchg.65).aspx如果发现数据库为“Dirty Shutdown”状态,需要修复该数据库。

而且通常这种状态,通过“eseutil /r” 软修复是不能修复数据库的,而需要硬修复。

2)需要硬修复该数据库,通过以下命令:eseutil.exe /P “数据库EDB文件全路径”Eseutil /P 修复模式/zh-cn/library/aa996773(v=exchg.65).aspx如何在各种情况下运行 Eseutil /P(修复)/zh-cn/library/aa997215(v=exchg.65).aspx3)同时做完硬修复后,建议做以下两个操作完成整个修复的操作:在 /D 模型下运行 Eseutil,以完整地重建索引并对数据库进行碎片整理eseutil.exe /d “数据库EDB文件全路径”如何运行 Eseutil /D(碎片整理)/zh-cn/library/aa995748(v=exchg.65).aspx然后运行 ISInteg,以便在应用程序级别修复数据库isinteg -s “服务器名称” -fix -test alltests注意: 执行该命令后需选择需要修复的数据库,该数据库必须是卸载状态的(offline)。

数据库的备份与恢复 思迅培训课件

数据库的备份与恢复 思迅培训课件


DBCC CHECKDB('hbposv6_branch', REPAIR_REBUILD)

GO

点击‘运行’,数据库进行修复。

请注意修复结果是否有错误,错误是否已被修复,如果发现错误但是没有被修复输入下面的SQL语句。

USE MASTER

exec sp_dboption 'hbposv6_branch', 'single user', 'TRUE'
数据库的备份/恢复与修复
一。数据库的备份
• 一。在思迅软件中备份,前提是软件可以正 常打开
• 二。在企业管理器中备份,适用于软件打 不开,但SQL企业管理器可以打开的情况
• 三。直接把数据文件拷出来,适用于软件 和SQL企业管理器都打不开的情况
在思迅软件中备份
• 在软件系统管理中数据库管理模块下
三。置疑数据库的修复
• 一。做日结或者数据传输的过程中,服务 器突然断电
• 二。硬盘存在坏道 • 三。数据盘,磁盘格式为FAT32,而数据文
件大小已经超过此格式所允许的最大容量 • 以上几种情况都很容易造成数据库的置疑
置疑数据库的修复
• 1.停止SQL Server的服务, • 备份SQL Server安装目录下的\data子目录下故障数据库的两个文件,一个数据文件
hbposv6_branch.mdf, • 一个hbposv6_branch.ldf(也有可能非此命名),同时查看磁盘空间是否有足够的空间;
• 2.启动SQL Server服务(如已停止),创建一个新的数据库,命名为原来数据库的名字。 • 3.停止SQL Server • 4.把老数据库的MDF文件(hbposv6_branch_data.mdf)替换新数据库的相应的MDF文件,并把LDF

数据库置疑修复评析

数据库置疑修复评析

数据库置疑修复[评析]数据库置疑修复数据库置疑的解决方法:(1):如果是严重的置疑,就这样解决停止SQL服务,备份你的置疑的数据库的数据文件(直接将MDF,LDF文件拷贝出去就可以).然后启动SQL服务,再删除置疑的数据库然后按下面的步骤处理:1.新建一个同名的数据库2.再停掉sql server(注意不要分离数据库)3.用原数据库的数据文件覆盖掉这个新建的数据库4.再重启sql server5.此时打开企业管理器时会出现置疑,先不管,在SQL查询分析器中执行下面的语句(注意修改其中的数据库名)6.完成后(刷新数据库)一般就可以访问数据库中的数据了,这时,数据库本身一般还有问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'Gosp_dboption '置疑的数据库名', 'single user', 'true'GoDBCC CHECKDB('置疑的数据库名')Goupdate sysdatabases set status =28 where name='置疑的数据库名'Gosp_configure 'allow updates', 0 reconfigure with overrideGosp_dboption '置疑的数据库名', 'single user', 'false'Go------------------------------------------------------------------------------------------------------------------------(2)重置置疑状态如果 SQL Server 因为磁盘驱动器不再有可用空间,而不能完成数据库的恢复,那么 Microsoft? SQL Server? 2000 会返回错误 1105 并且将 sysdatabases 中的 status 列设为置疑。

数据库质疑_BCP修复方法

数据库质疑_BCP修复方法
ORDER BY NAME
把查询的结果集全部复制下来,新建一个文本文件取名为“导入.bat”把结果集复制进去并保存,把该文件存放在d盘目录下。
3.运行“导出.bat”(注意:该文件双击即可运行),数据库中的数据会倒出到TESTDB目录中。
4.删除原来的问题数据库,重新建立新的数据库。
5.在查询分析器中选择新建的数据库运行:
在进行操作前,请先备份数据库(备份mdf和log文件)
操作步骤:
1.首先在D盘建立TESTDB目录,并在查询分析器中选择思迅数据库运行:
use hbyjtv6 ---(用问题数据库名代替hbposv6)
select 'bcp 问题数据库..'+name + ' out '+'d:\testdb\'+name+'.txt -c -Usa -S 服务器名小写 -P 数据库SA密码' FROM SYSOBJECTS WHERE TYPE = 'U'
select 'delete '+name FROM SYSOBJECTS WHERE TYPE = 'U'
然后把返回的结果集复制,新建一个查询分析器窗口,把复制的内容粘贴下运行!
6.最后运行“导入.bat” ,倒入成功后就恢复数据库了!
7.最后在查询分析器中选择数据库运行
8.最后检查数据。
注意:a.请根据语句中的汉字提示,进行修改对应内容。如:语句中的“问题数据库”,修改为hbyjtv7
b.此方法适用于索引坏,DBCC不能修复的数据库,另置疑数据库也可用此方法修复!

数据库损坏和置疑修复方法

数据库损坏和置疑修复方法

数据库损坏和置疑修复方法为了修复数据库损坏,可以采取以下方法:1.备份恢复:如果有最新的备份文件,可以通过备份文件进行恢复。

恢复时应注意将损坏的数据库与备份文件进行比对,避免将损坏的数据库文件恢复到备份文件上。

2.日志文件恢复:数据库管理系统通常会有日志文件来记录数据的修改操作,使用日志文件可以恢复损坏的数据库。

通过日志文件,可以找到最近一次正常操作的记录,并恢复到该记录之后的状态。

3.数据库修复工具:数据库管理系统通常都提供了数据库修复工具,可以用于修复损坏的数据库。

修复工具能够检测数据库的完整性,并修复数据文件中的错误或者丢失的数据。

4.数据库重建:如果无法通过备份恢复或通过修复工具修复数据库,可以尝试重建数据库。

重建数据库可以通过创建新的数据库,然后将数据从旧数据库中导出并导入到新数据库中,实现数据的恢复。

5.异地备份:在数据库损坏之前,应该做好数据的备份工作,并将备份数据存储在其他地方。

这样即使数据库发生损坏,也能够通过备份数据进行恢复。

在修复数据库损坏时,需要注意以下几点:1.数据库损坏后,必须立即停止对数据库的操作,以免进一步损坏数据。

2.在使用数据库修复工具时,应该对数据库进行完整备份,以防修复过程中出现意外情况。

3.在修复过程中,应该小心操作,避免进一步损坏数据库文件或数据。

4.在数据库损坏修复完成后,应该对数据库进行全面的测试,以确保数据库的完整性和可用性。

5.定期进行数据库维护和优化工作,以减少数据库损坏的可能性。

总之,数据库损坏是一种常见的情况,但通过备份恢复、日志文件恢复、修复工具、数据库重建等方法,可以有效修复损坏的数据库。

在数据库损坏修复过程中,需要小心操作,避免进一步损坏数据。

同时,定期进行数据库维护和优化工作,可以减少数据库损坏的发生。

SQL数据库紧急修复

SQL数据库紧急修复

SQL数据库紧急修复一.如果sql服务器因为异常断电或者磁盘空间不足很容易引起数据库出现置疑的问题.如下图.(图片网上搜的)出现这样的问题,其实不用慌张,利用sql自带的数据修复功能就能修复好,一般情况下只要不是因为磁盘坏道引起的置疑问题都是可以修复的.二.首先关闭所有的sql用户连接该步骤应该都会吧.不会的话,我告诉你,有3个办法.1. 拔掉此机器的网线. 呵呵, 这种方法立竿见影, 但是可能对其他的连接造成影响.2. 通知连接至此数据库的用户断开连接. 如果可能连接的用户很多或不知道哪个用户正在连接的话就不可行了.3. 在SQL Server中用命令StopLogin强行断开连接.详细说明如下:使用说明:StopLogin @UFMeta_006该操作为强行断开连接的数据库ummeta_006, 如果您要断开所有数据库的连接进行维护的话则只要执行[StopLogin ’’]即可.三,停止sql服务,将置疑的数据库日志文件删掉就是那个ldf文件,然后将数据库文件剪切到其他地方去,然后启动sql服务,新建一个和置疑数据库名字一模一样的数据库.然后再次停止sql服务,将刚才置疑的数据库文件复制回去替换掉新建的.然后再次启动sql服务.四,这样启动sql服务之后在企业管理器里面看到该数据库还是置疑.但是因为ldf文件已经重建,我们可以开始对它进行修复了.首先设置数据库允许直接操作系统表。

此操作可以在SQL Server Enterprise Manager里面选择数据库服务器,按右键,选择“属性”,在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。

也可以使用如下语句来实现。

use mastergosp_configure 'allow updates',1goreconfigure with overridego然后设置UFMeta_006紧急修复模式update sysdatabases set status=-32768 where dbid=DB_ID('UFMeta_006') 此时可以在SQL Server Enterprise Manager里面看到该数据库为“紧急模式”。

SQLserver2000数据库修复办法总结

SQLserver2000数据库修复办法总结

SQLserver2000数据库修复办法总结Praymid 戴华倪总结步骤如下:1、检测数据库,使用命令(Dbcc checkdb)拿到数据库后附加到本地SQLserver使其运行,打开企业管理器,查看它。

同时打开查询分析器,在里面输入Dbcc checkdb 检测数据库命令然后回车即可以看到数据库的分析资料看到问题,评注:拿到问题先不要盲目的卸载SQLServer,本次因为新手,上手后就把数据库卸载,这样就耗费了一天的时间,过没有任何作用,测试服务器的完整性可以拿一个好的数据库做对比,自己可以建一个“test”,如果测试数据库运行正常,则不需要对服务器做任何改动。

千万不要改动系统,麻烦会更大。

提示:错误会以红色显示。

2、简单修复:命令:dbcc checkdb输入以下两句尝试修复。

DBCC CHECKDB('AIS20110120172605',repair_allow_data_loss)DBCC CHECKDB('AIS20110120172605',repair_rebuild)不管他究竟哪里错了,先用这两句试试一般的索引系统文件丢失,SQLserver 都可以解决这个问题,基本就差不多了。

但是对于主键索引损坏,这个命令基本修不好,所以对一个满身是伤的数据库,他可以修复70%。

注:修复时系统提示必须要在单用户模式下才可以生效,用户可以去企业管理器,对要修理的数据库:右击属性—选项—限制访问—单用户。

也可以使用以下语句实现:ALTER DATABASE AIS20110420091143 SET single_USERGO 改为单用户ALTER DATABASE AIS20110420091143 SET MULTI_USERGO 改为多用户。

继续使用dbcc checkdb检测,如果继续报错。

再次运行:DBCC CHECKDB('DataBasename') with NO_INFOMSGS,PHYSICAL_ONLY然后再运行:DBCC CHECKDB(' DataBasename ',repair_allow_data_loss) WITH TABLOCK 再次运行:DBCC CHECKDB('DB name') 系统显示修复成功,说明本次问题主要由索引等数据库系统本身问题引起,这样的修复可能会导致数据丢失,但是绝对不会是大批丢失,基本没有影响。

数据库故障恢复的应急处理流程

数据库故障恢复的应急处理流程

数据库故障恢复的应急处理流程数据库是企业重要的信息存储和管理工具,在企业的日常运营中扮演着至关重要的角色。

然而,由于各种原因,数据库可能会发生故障,导致企业的业务中断和数据丢失。

针对数据库故障,进行应急处理是至关重要的。

本文将介绍数据库故障恢复的应急处理流程及相关考虑因素。

1. 确定故障类型和范围当数据库出现故障时,首先需要确定故障的类型和范围。

故障类型可能包括硬件故障、软件故障、网络故障等。

而故障范围可能涉及整个数据库系统、某个数据库实例或者某个表、某个分区等。

2. 恢复前的准备工作在正式进行数据库恢复之前,需要进行一些准备工作,以确保数据库的数据得以保护。

这些准备工作可能包括:- 备份数据和日志文件:在进行数据库故障恢复之前,首先需要确保有可靠的数据和日志备份。

这些备份文件将在后续的恢复中发挥重要作用。

- 确认数据库签出点:数据库签出点是指故障发生前数据库的一个一致的状态。

通过确认数据库签出点,可以确保在恢复时数据的完整性。

- 准备恢复工具和资料:为了更好地进行数据库恢复,需要准备恢复工具和相关的资料,如故障诊断工具、相关文档和记录等。

3. 分析故障原因在确认故障类型和范围之后,需要进行详细的故障原因分析。

通过对故障原因的分析,可以更好地制定恢复方案和采取相应的措施。

根据故障类型,可能需要进行硬件故障分析、软件故障诊断、网络故障排查等。

4. 制定恢复方案根据对故障原因的分析,需要制定相应的恢复方案。

恢复方案应包括以下要素:- 恢复目标:明确恢复的目标,即使数据库能够尽快恢复到正常工作状态。

- 恢复步骤:具体列出进行故障恢复的步骤和流程。

- 资源需求:明确进行故障恢复所需的资源,如人力资源、硬件资源、软件资源等。

- 时间估计:在制定恢复方案时,需要对恢复所需的时间做出合理的估计,以便组织其他业务和资源。

5. 执行恢复方案按照制定的恢复方案,逐步执行恢复步骤。

在执行过程中,需要密切关注恢复的进度和结果。

请简述数据库恢复的流程

请简述数据库恢复的流程

数据库恢复的流程主要包括以下步骤:1.备份数据:在进行数据库恢复之前,首先要进行数据备份,确保数据库的数据能够存储到另一份磁盘或设备中。

备份时,应按照特定的计划进行,如每日、每周、每月、每季度等不同的时间进行备份。

同时,备份数据的保存位置需要备份到可靠的备份设备中。

2.确定原因和严重程度:在数据库恢复之前,需要找出数据库损坏或数据丢失的原因和严重程度。

这有助于选择最合适的恢复方法。

如果数据库损坏或数据丢失的原因已经被确定,可以有针对性地选择适合的恢复方法。

同时,可以使用数据库诊断工具来检测数据库的健康状况,以判断数据库是否可以继续使用。

3.故障种类处理:针对不同种类的故障,如事务故障或系统崩溃,应采取不同的恢复策略。

例如,对于事务故障,需要撤销事务UNDO或重做REDO;对于系统崩溃,应采取检查点恢复机制,对未完成的事务进行撤销或重做。

4.执行恢复:根据数据库损坏或数据丢失的原因和严重程度,选择适合的恢复方法。

如果数据库文件被损坏,可以使用数据库恢复软件进行恢复;如果数据库文件丢失,可以使用备份数据进行恢复。

5.附加数据库:如果数据库文件被复制或移动,需要附加数据库。

可以通过执行CREATE DATABASE语句来附加数据库文件。

如果附加失败,可以尝试使用dbcc rebuild_log语句重建日志文件。

6.测试恢复结果:在完成数据库恢复后,需要进行测试以确保恢复成功。

测试可以通过查询数据库中的数据、运行应用程序等方式进行。

7.监控和优化:在完成数据库恢复后,应持续监控和优化数据库的性能和安全性,以避免再次发生故障。

数据库数据丢失与恢复方法分析

数据库数据丢失与恢复方法分析

数据库数据丢失与恢复方法分析当数据库发生数据丢失时,无论是意外删除、硬件故障还是人为错误,都可能导致数据的损失。

对于企业和组织来说,数据库中的数据是非常重要和宝贵的资产,因此及时恢复丢失的数据是至关重要的。

本文将分析数据库数据丢失的原因以及常用的恢复方法。

一、数据库数据丢失的原因1. 意外删除:用户或管理员错误地删除了重要的数据。

2. 软件故障:数据库软件出现问题或崩溃,导致数据的丢失。

3. 硬件故障:硬盘故障、电源问题或服务器故障可能导致数据库数据的丢失。

4. 病毒攻击:恶意软件或病毒可能破坏数据库系统,导致数据丢失。

5. 自然灾害:火灾、洪水、地震等自然灾害可能导致数据库服务器损坏,从而造成数据丢失。

二、常用的数据库数据恢复方法1. 备份和恢复备份数据是最常用和有效的恢复方法之一。

定期备份数据库可以帮助恢复数据并减少损失。

可以使用物理备份或逻辑备份来实现对数据库的备份。

物理备份是直接备份数据库文件和记录,而逻辑备份是导出数据库中的数据到可读的格式,如SQL语句或CSV文件。

当数据丢失时,可以使用备份文件来恢复丢失的数据。

然而,备份文件的更新和保存也需要注意,并且需要测试备份文件是否可用。

2. 事务日志恢复许多数据库系统提供了事务日志功能,可以记录数据库中的操作和更改。

当数据库发生故障导致数据丢失时,可以利用事务日志来恢复数据库。

通过回放事务日志中记录的操作,在故障发生前的状态下重建数据库,并将记录应用到数据库中来恢复数据。

然而,使用事务日志恢复的过程可能比较复杂,需要详细了解数据库系统的日志恢复机制。

3. 数据库镜像数据库镜像是一种复制数据库到一个或多个镜像服务器的方法。

当主数据库发生故障时,可以使用镜像数据库来提供持续的数据访问。

镜像数据库可以作为备份和恢复的补充,提供了更高的可用性和容错能力。

然而,数据库镜像需要额外的硬件和配置成本,并且需要确保镜像数据库与主数据库的同步。

4. 第三方数据恢复工具有一些专门的数据恢复工具可以帮助恢复损坏或丢失的数据库。

数据库损坏如何修复(bcp)

数据库损坏如何修复(bcp)
,该方法叫bcp处理):
在进行操作前,请先备份数据库(备份mdf和log文件)
操作步骤:
1.首先在D盘建立TESTDB目录,并在查询分析器中选择思迅数据库运行:
use hbposv5
go
select 'bcp hbposv7..'+name + ' out '+'d:\testdb\'+name+'.txt -c -U sa -S 127.0.0.1 -P 17.3913.82' FROM SYSOBJECTS WHERE TYPE = 'U'
注意:a.请根据语句中的汉字提示,进行修改对应内容。如:语句中的“hbposv7”,修改为hbposv5
b.此方法适用于索引坏,DBCC不能修复的数据库,另置疑数据库也可用此方法修复!
use hbposv5
go
update t_sys_system set sys_var_value=(select max(flow_id) from t_im_flow where num2=1) where sys_var_id='ioflow_pointer'
go
8.日结,检查数据。
ORDER BY NAME
把查询的结果集全部复制下来,新建一个文本文件取名为“导出.bat”把结果集复制进去并保存,把该文件存放在d盘目录下。
2.在查询分析器中选择思迅数据库运行:
select 'bcp hbposv7..'+name + ' IN '+'d:\testdb\'+name+'.txt -c -U sa -S 127.0.0.1 -P 17.3913.82' FROM SYSOBJECTS WHERE TYPE = 'U'

只有mdf和ldf文件,甚至只有mdf文件,如何恢复数据库档

只有mdf和ldf文件,甚至只有mdf文件,如何恢复数据库档

只有mdf和ldf文件,甚至只有mdf文件,如何恢复数据库2010-04-19 10:34只有mdf和ldf文件,甚至只有mdf文件,如何恢复数据库1. 首先确认已经备份了.mdf和.ldf文件。

2. 在SQL Server中新建一个同名的数据库,然后停止SQL Server服务。

3. 用原有的.mdf和.ldf文件覆盖新建数据库对应的.mdf和.ldf文件。

4. 重新启动SQL Server服务,这是应该会看到这个数据库处于置疑(Suspect)状态。

(人品好的话,这个时候数据库就已经恢复正常了,上次xrf的数据库就是这样被我恢复的。

人品不好的话,下面的步骤也不行,我有一次就是找了一个北京做数据恢复的公司才恢复完毕。

)5. 在SQL查询分析器中执行以下命令,以允许更新系统表:use mastergosp_configure ‘allow updates’,1reconfigure with overridego6. 将这个数据库置为紧急模式:update sysdatabases set status = 32768 where name = 'db_name'go7. 使用DBCC CHECKDB命令检查数据库中的错误:DBCC CHECKDB(‘db_name’)GO8. 如果DBCC CHECKDB命令失败,请转至第10步,否则先将数据库置为单用户模式,再尝试对其进行修复:sp_dboption 'db_name',’single user’,’true’DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)GO如果在执行DBCC CHECKDB(‘db_name’, REPAI R_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话,则重新启动SQL Server服务,然后继续尝试。

9. 如果DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)命令失败,请转至第10步,否则若成功修复了数据库中的错误:重新执行DBCC CHECKDB(‘db_name’)命令,确认数据库中已没有错误存在。

数据库故障排查与修复的方法与案例分享

数据库故障排查与修复的方法与案例分享

数据库故障排查与修复的方法与案例分享近年来,随着互联网的迅猛发展和技术的不断进步,数据库已经成为了企业核心信息的存储和管理工具。

然而,由于各种原因,数据库可能会出现故障,严重影响了企业的正常运行。

在此文中,我将和大家分享一些数据库故障排查与修复的方法和实际案例,以帮助各位解决数据库故障问题。

1. 故障排查的基本步骤数据库故障的排查可按照以下步骤进行:1.1 收集故障现象在故障发生时,注意记录故障现象,包括错误信息、异常行为、异常表现等。

这有助于后续的故障定位和修复。

1.2 检查硬件环境数据库所运行的硬件环境可能会成为故障的源头。

检查服务器、存储设备等硬件是否正常工作,确保网络通畅。

1.3 检查网络连接在数据库故障排查中,网络连接也是常见的问题。

检查网络是否稳定,查看网络设备是否正常工作,亦或是判断是否存在网络流量异常。

1.4 检查数据库配置配置错误常常导致数据库故障。

查看数据库配置文件是否正确且完整,确保配置参数与硬件资源相适应,避免资源过度占用。

1.5 检查数据库日志数据库日志记录了大量的运行信息,能够帮助我们了解到故障发生的时间、条件和规模等。

通过仔细分析日志,可能能够找到问题的原因。

1.6 检查数据完整性数据库的数据完整性可能受损,导致系统故障。

使用一些工具或查询来验证数据的完整性,确保数据库中的数据不被破坏。

1.7 逐一排查故障因素根据收集到的信息和检查结果,一步步地排查故障的原因。

可以使用一些命令或查询来验证假设和分析的结果。

1.8 进行故障修复根据故障的具体原因进行修复,可能需要重新配置、重启数据库、修复表结构等。

确保在修复之前进行备份,以防意外情况发生。

2. 实际案例分享2.1 故障排查案例:数据库连接失败某公司的数据库突然出现了连接失败的故障,导致系统无法正常运行。

根据以上的排查步骤,我们可以逐步定位故障:步骤1:收集故障现象用户报告无法访问数据库,出现连接错误的提示。

步骤2:检查硬件环境通过检查服务器和网络设备,发现硬件正常工作。

实战篇:OracleDataGuard出现GAP修复完整步骤

实战篇:OracleDataGuard出现GAP修复完整步骤

实战篇:OracleDataGuard出现GAP修复完整步骤前⾔DG GAP 顾名思义就是:DG不同步,当备库不能接受到⼀个或多个主库的归档⽇志⽂件时候,就发⽣了 GAP。

那么,如果遇到GAP如何修复呢?且听我细细道来~⼀、介绍DG GAP 主要分为以下两类情况:1、主库归档⽇志存在,可以通过配置 Fetch Archive Log(FAL) 参数,⾃动解决归档 GAP。

2、主库归档⽇志丢失,需要⼈⼯⼲预来修复。

不同 Oracle 版本的 GAP 修复⽅式也不尽相同,下⾯分别介绍不同版本的⽅式!11G的处理步骤:a.在主库上创建⼀个备库的控制⽂件b.以备库的当前SCN号为起点,在主库上做⼀个增量备份c.将增量备份拷贝到备库上d.使⽤新的控制⽂件将备库启动到mount状态e.将增量备份注册到RMAN的catalog,取消备库的恢复应⽤,恢复增量备份f.开启备库的恢复进程12C的新特性(RECOVER … FROM SERVICE)18C的新特性(RECOVER STANDBY DATABASE FROM SERVICE)Oracle随着版本的升级,逐渐将步骤缩减,进⾏封装,18C之后可谓是达到了所谓的⼀键刷新,恢复DG同步。

⼆、实战下⾯我们通过实验来进⾏演⽰如何修复:11G常规修复12C新特性(RECOVER … FROM SERVICE)修复18C新特性(RECOVER STANDBY DATABASE FROM SERVICE)修复安装测试环境可以使⽤博主编写的 Oracle ⼀键安装脚本,同时⽀持单机和 RAC 集群模式!开源项⽬:Install Oracle Database By Scripts!更多更详细的脚本使⽤⽅式可以订阅专栏:Oracle⼀键安装脚本。

三、11G常规修复⾸先,模拟备库断电,主库切⼏个最新的归档,然后⼿⼯删掉,重新开启DG同步。

备库停⽌DG同步进程:sqlplus / as sysdbaALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;shutdown immediate主库切换多次归档:sqlplus / as sysdbaalter system switch logfile;主库删除最近⼏个归档⽇志:rm 1_34_1070147137.arcrm 1_33_1070147137.arc备库开启同步进程:startupALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;查看GAP:sqlplus / as sysdbaSELECT * FROM V$ARCHIVE_GAP;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- --------------1 32 34SELECT max(sequence#) from v$archived_log where applied='YES';MAX(SEQUENCE#)--------------31注意:当前DG数据库已存在GAP,GAP⽇志为:32—34。

Oracle数据库文件损坏修复(断电情况下)

Oracle数据库文件损坏修复(断电情况下)

现场情况:1、数据库没有作归档,2、数据都存放在system表空间3、没有备份状况:操作系统由于磁盘原因出现宕机,用户强行按电源关闭系统,数据库无法启动。

处理:Sql代码1.SQL> recover database;2.ORA-00283: recovery session canceled due to errors3.ORA-12801: error signaled in parallel query server P0024.ORA-10562: Error occurred while applying redo to data block (file# 1, block#4568)5.ORA-10564: tablespace SYSTEM6.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'7.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 5768.ORA-00600: internal error code, arguments: [6101]9.检查日志信息如下:Oracle代码1.Mon Nov 1915:38:5020072.ALTER DATABASE RECOVER database3.Mon Nov 1915:38:5020074.Media Recovery Start5. parallel recovery started with 3 processes6.Mon Nov 1915:38:5020077.Recovery of Online Redo Log: Thread 1 Group 3 Seq 16 Reading mem 08. Mem# 0 errs 0: /opt/oracle/oradata/orcl/redo03.log9.Mon Nov 1915:38:50200710.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:11.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []12.Mon Nov 1915:38:50200713.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:14.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []15.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)16.ORA-10564: tablespace UNDOTBS117.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'18.ORA-10560: block type 'KTU UNDO BLOCK'19.Mon Nov 1915:38:51200720.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:21.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []22.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)23.ORA-10564: tablespace UNDOTBS124.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'25.ORA-10560: block type 'KTU UNDO BLOCK'26.Mon Nov 1915:38:51200727.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:28.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 4568)29.ORA-10564: tablespace SYSTEM30.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'31.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 57632.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []33.Mon Nov 1915:38:54200734.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:35.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []36.Mon Nov 1915:38:54200737.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:38.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)39.ORA-10564: tablespace SYSTEM40.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'41.ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 23742.ORA-00607: Internal error occurred while making a change to a data block43.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []44.Mon Nov 1915:38:54200745.Media Recovery failed with error 1280146.ORA-283 signalled during: ALTER DATABASE RECOVER database ...从上面信息中抓取了一个信息:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)针对这个错误解决如下:Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# string, block# string)2.Cause: See other errors on error stack.3.Action: Investigate why the error occurred and how important isthe data block. Media and standby database recovery usually ca n continue if user allows recovery to corrupt this data block。

数据库备份与恢复

数据库备份与恢复

数据库备份与恢复
2. 系统故障的恢复
系统故障造成数据不一致的原因有两个:一个是未完成的 事务对数据库的更新可能已经写入数据库;另一个是已提交 的事务对数据库的更新可能还留在缓冲区没来得及写入数据 库。因此,这时的恢复操作就是要撤销故障发生时未完成的 事务,重做已提交的事务。
系统的恢复步骤如下: (1)正向扫描日志文件(即从头扫描日志文件),找出在 故障发生前已经提交的事务(这些事务既有事务的开始记录, 也有事务的结束记录),将其事务标识记入重做队列,同时 找出故障发生时尚未完成的事务(这些事务只有开始记录, 无相应的结束记录),将其事务标识记入撤销队列。 (2)对撤销队列中的各个事务进行撤销处理。进行撤销处 理的方法是,反向扫描日志文件,对每个撤销事务的更新操 作执行逆操作,即将日志记录中“更新前的值”写入数据库。 (3)重做队列中的各个事务进行重做处理。进行重做处理 的方法是:正向扫描日志文件,对每个重做事务重新执行日 志文件登记的操作,即将日志记录中“更新后的值”写入数 据库。
静态转储是在系统中无运行事务时进行的转储,即转储操作 开始的时刻,数据库处于一致性状态,转储期间不允许(或不 存在)对数据进行任何存取、修改活动。显然,静态转储得到 的一定是一个数据一致性的副本。静的事务必须等待转储结束 后才能执行,这显然会降低数据库的可用性。 2)动态转储
热备份也称作联机备份。它允许用户在备份时访问数据库, 是一种边工作边备份的工作模式。不过,当有大量的更新批作 业运行时进行此类备份,备份效率比较低。因此,在热备份的 过程中会产生许多重复记录。
数据库备份与恢复
2. 逻辑备份 逻辑备份是指利用export等工具执行SQL语句将
数据库中的数据读取出来,然后再写入一个二进制文 件中;在需要恢复数据时,利用import等工具从该二 进制文件读取数据,并通过执行SQL语句的方式将它 们导入数据库中。逻辑备份可以在数据库中完成特定 对象(如表、存储过程)的备份,或者把对象从一个 数据库移植到另一个数据库。与物理备份相比,逻辑 备份可以将数据库中的数据导入其他的数据库,甚至 运行于其他操作系统的数据库中,因此具有更大的灵 活性。

常规SQL SERVER数据库置疑后恢复步骤

常规SQL SERVER数据库置疑后恢复步骤

常规SQL SERVER数据库置疑后恢复步骤--1.恢复步骤:--a.将smlog_log.ldf文件备份到其它目录下;--b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf;--c.执行以下语句修改数据库的状态:use Mastergoupdate sysdatabases set status=32768 where name='数据库名称' --修改状态,設為緊急狀態goshutdown with nowait --停止数据库服务器go--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码重新启动SQL:sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER--e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态:select Name,Status from sysdatabases where Name='数据库名稱'--f.执行以下代码新建日志文件:dbcc traceon(3604)--跟踪dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名要有全路径和扩展名--dbcc rebuild_log('prs_msc','d:\mscsql\mssql\data\prs_msc_log.ldf --g.将数据库置回正常状态:update sysdatabases set status=0 where name='数据库名称'--h.重新启动数据库后执行以下语句检查数据库:DBCC CHECKDB --如果执行完有错误用以下语句修复--i.要修复数据库必需将数据库改为单用户模式:Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)--j.执行以下语句修复数据库:DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS) REPAIR_ALLOW_DATA_LOSS:是比较高级的修复方式REPAIR_FAST:是简单快速的修复方式/*處理状态就为"置疑"的數據庫备份数据文件,然后按下面的步骤处理:1.新建一个同名的数据库(数据文件与原来的要一致)2.再停掉sql server(注意不要分离数据库)3.用原数据库的数据文件覆盖掉这个新建的数据库4.再重启sql server5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.*/USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1GORECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'Gosp_dboption '置疑的数据库名','single user','true'GoDBCC CHECKDB('置疑的数据库名')Goupdate sysdatabases set status=28 where name='置疑的数据库名' Gosp_configure 'allow updates',0GOreconfigure with overrideGosp_dboption '置疑的数据库名', 'single user','false'Go关于SQL数据库置疑的修复方法发布日期:2008/11/17 18:10:22 来源:作者:点击:1078斑竹广告联盟问题现象:数据库后面有“置疑”字样,查看系统事务日记出现以下错误:错误1---------------------------------------------错误: 823,严重度: 24,状态: 2I/O error 23(数据错误(循环冗余检查)。

金蝶k3数据库常见问题及数据库修复恢复方法

金蝶k3数据库常见问题及数据库修复恢复方法

金蝶K3数据库常见问题及数据库修复恢复方法(一)1、明细帐查询错误2、错误描述:帐套在查询明细帐(包括数量明细帐)时提示“产生未知错误”或提示:发生未知错误,系统将当前操作取消,错误号为0,请与金蝶公司联系。

3、问题原因:数据库表Glbal, Glpnl 表损坏4、处理方法:备份当前数据表后,导入新的表结构,并把原数据导入到新表,再利用Check 检查关系的完整性。

5、报表取数出现翻倍6、错误描述:在报表中进行数据重算后,数据出现双倍。

7、问题原因:系统在凭证过账时产生过账错误。

(报表公式错误除外)8、处理方法:具体步骤如下:9、1)进行反过帐、反结帐到出错期间,10、2)安装新版本软件(建议用比较高的版本),11、3)在新版本软件中恢复操作权限,12、4)在新版本软件中重新进行过帐、结帐13、注意:如果是偶尔在最近一期才出现这种现象,则只需将数据中的Glpnl 表中的记录删除,再反过帐→反结帐→过帐→结帐,即可。

3、利用ODBC 修复账套操作步骤;1)、打开Office 工作组管理文件Wrkgadm.Exe 链接System.Mda 文件2)、取消System.Mda 的登录密码:进入Access,不打帐套,通过“工具--安全--用户组与帐号”---- “更改登录密码”,输入原密码后,直接确定。

3)、设置Odbc:进入Win2000 的ODBC,添加--选择“Driver Do Microsoft Access (*.Mdb)”---完成4)、数据库---选择System.Mda 所在路径和它的文件名5)、设置高级选项:输入登录的名称(Morningstar);此时不要输入密码,它也没有密码的。

6)、设置修复选项:选择需要修复的帐套,确定。

7)、待系统将提示修复成功,可以用Access 和软件检测试数据了,结合Check 检查该帐套的完整性。

8)、修改完成后,建议回到Access 中,将密码还原,以确保数据库的安全。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

关于数据库修复的一些经验
1,数据库一般有一致性错误和分配性错误两种,我们经常处理的是一致性错误
处理一致性错误一般可以根据下面的语句修复
dbcc checkdb --检查数据库--
EXEC sp_dboption 'kmjxc_std', 'single user', 'TRUE' ---设置数据库kmjxc_std为单用户--
open #tmp_cur
fetch next from #tmp_cur into @branch_no,@item_no,@oper_date
while @@fetch_status = 0
begin
select * into #tmp_1 from pos_t_daysum
SELECT * FROM sysobjects
where id in ('106158','106186','106190','106191','106193','1422628111') --查询错误ID的表名--
dbcc checktable ('ic_t_jxc_daysum',repair_allow_data_loss) -------修复表
dbcc checktable ('ic_t_jxc_daysum',REPAIR_REBUILD) -------修复表索引
EXEC sp_dboption 'kmjxc_std', 'single user','FALSE'
from pos_t_daysum -----这里是需要修复的表名
group by branch_no,item_no,oper_date -----主健的列名
having count(1) > 1
order by branch_no,item_no,oper_date -----主健的列名
end
close #tmp_cur
deallocate #tmp_cur
如果是索引问题,重建索引即可
dbcc checkdb ('kmjxc_std',repair_allow_data_loss) -------修复数据库
checkdb ('kmjxc_std',REPAIR_REBUILD) ----------------修复数据库索引
主键与主键索引的关系:
在oracle中,我们创建一个主键,则同时自动创建了一个同名的唯一索引;删除主键,则主键约束和对应的唯一索引都删除了。这是我们经常见到的现象。 发出一个创建主键的sql,oracle其实执行了两步:创建主键约束、创建/关联 唯一索引。步骤是这样的:创建主键约束时,检查该主键字段上是否已经存在唯一索引。若不存在,则自动创建同名唯一索引;若存在,则直接创建主键约束,并将该约束和已经存在的唯一索引对应上。 删除主键约束时,可以决定是否保留对应的索引;删除唯一索引时,若存在对应的主键约束,则不能删除。 总之,存在主键约束,则肯定存在与之对应的唯一索引,而存在唯一索引,不一定对应着有主键约束。
where id in ('106158','106186','106190','106191','106193','1422628111') --查询错误ID的表名--
然后打开企业管理器找到表右键设计表取消主键--保存---在设置主键---保存
如果取消主键---保存的时候保存不了提示有重复的,可以按照下面的步骤操作:
在执行下面的语句之前请把出错的表的主健去掉,
declare @branch_no char(6), ----下面3行是定义主健的列,可以是多个
@item_no char(13),
@oper_date char(8)
declare #tmp_cur cursor
for
select branch_no,item_no,oper_date -----主健的列名
where branch_No = @branch_no and item_no = @item_no and oper_date = @oper_date
delete pos_t_daysum
where branch_No = @branch_no and item_no = @item_no and oper_date = @oper_date
print object_name(26557939712) -------查询表
如果上面的语句修复不了,一般是由于数据的主健有重复或者是数据索引有问题,简单点的操作方法是
先查出SELECT * FROM sysobjects
insert into pos_t_daysum
select top 1 * from #tmp_1 order by branch_no,item_no,oper_date
drop table #tmp_1
fetch next from #tmp_cur into @branch_no,@item_no,@oper_date
相关文档
最新文档