标签: corruption

假设 dbcc checkdb 在一页上显示损坏。

假设我想通过仅恢复损坏的页面来修复此问题。

所以我进入恢复页面用户界面，单击按钮找到损坏的页面，输入完整和日志备份文件并恢复。

我的问题是 - sql 服务器检查给定完整备份中页面是否损坏的方式是什么？

我刚刚开始学习数据库和使用 mysql。我读到数据库比拥有大的 ascii 文本文件更可靠，并且随着 ascii 文本文件变大，它们更容易损坏。

有人可以解释为什么会出现这种情况以及数据库如何在高层次上防止这种情况吗？谢谢你。

不幸的是我的系统硬盘损坏了，现在我恢复了我的数据库。但是不能再次附加到SQL management studio 2005。错误是：

myfile.mdf is not a primary database file. (SQL server , error 5171)

关于损坏的 wiki建议立即通过停止 postmaster 并使用 来对数据库进行文件级备份tar，但我的印象是使用pg_basebackup是更好的选择。有什么理由我不应该使用吗pg_basebackup？

有什么方法可以让维护计划在单个实例上检查我的所有数据库？保养计划Check Database Integrity Task够吗？

我们公司多年来一直在运行 SQL Server 2005 服务器，但就在最近，我们遇到了一些麻烦。服务器配置了 RAID 5，阵列中有一个热备盘。其中一个磁盘出现故障，不久之后第二个磁盘也出现故障。不幸的是，我们没有对大部分数据进行备份（请不要说“应该有备份”的评论——我知道一个可靠的备份计划的重要性）。

所以我们两个磁盘都挂了，我们没有正式的 DBA，数据库也无法访问。我们的一名 IT 人员试图恢复 RAID 阵列，我们认为 RAID 开始重建，但他被命令将其关闭，因为担心在 RAID 重建期间可能会丢失数据。

我们将整个服务器发送给了一家数据恢复公司。他们花了两周时间在服务器上工作，首先对所有驱动器进行成像，然后从 RAID 重建数据。

我收到了一个包含所有“恢复”文件的硬盘。这是主要是数据库文件 (MDF) 和传输日志 (LDF) 的集合。服务器上的每个数据库仅包含一个 MDF 和一个 LDF。我目前无法访问原始服务器，因此我一直试图将这些数据库附加到另一台运行 SQL Server 2005 的服务器。但是，当我尝试重新附加任何数据库时，我遇到了问题。我收到的一些错误如下所示。我没有运气恢复任何这些文件。我按照本文中概述的步骤操作，即使那样也无法恢复任何文件。

我们向数据恢复公司支付了一大笔钱，用于从这台服务器恢复数据，我的任务是毫无疑问地证明这些数据对我们有用或没用。我只是没有确切的经验，所以我向你提出了一个问题，dba.stackexchange： 有没有办法恢复这些文件？

SQL Server 检测到基于逻辑一致性的 I/O 错误：pageid 不正确（预期为 1:134；实际为 0:0）。它发生在读取文件 'G:\Data\Data201309.mdf' 中偏移量 0x0000000010c000 处的数据库 ID 17 中的页面 (1:134) 期间。SQL Server 错误日志或系统事件日志中的其他消息可能会提供更多详细信息。这是威胁数据库完整性的严重错误情况，必须立即纠正。完成完整的数据库一致性检查 (DBCC CHECKDB)。此错误可能由多种因素引起；有关详细信息，请参阅 SQL Server 联机丛书。

文件“G:\Data\Data201112_log.ldf”的标头不是有效的数据库文件标头。PageAudit 属性不正确。（Microsoft SQL Server，错误：5172）

G:\Data\Data201005.mdf 不是主数据库文件。（Microsoft SQL Server，错误：5171）

处理数据库“Data201008”的日志时出错。如果可能，从备份中恢复。如果备份不可用，则可能需要重建日志。

SQL Server 检测到基于逻辑一致性的 I/O 错误：校验和不正确（预期：0xe9b50f3a；实际：0x162a0f84）。它发生在读取文件“G:\Data\Data200803.mdf”中偏移量 0x000000f9a00000 处的数据库 ID 17 中的页面 …

如果我理解正确，当用户更新数据库记录并提交事务时， commit() 调用将阻塞，直到完成以下步骤：

• 数据库记录了预写日志 (WAL) 中的更改。
• 数据库更新实际记录。
• 数据库删除 WAL 条目。

我有以下关于 WAL 的问题：

1. 数据库什么时候知道从 WAL 中删除条目是安全的？
2. WAL 是否暗示将记录写入磁盘两次（一次在 WAL 中，一次在数据库文件中）？
3. Postgres声称 WAL“显着减少了磁盘写入次数，因为只需要将日志文件刷新到磁盘”但是（回到问题 #1）在从数据库中删除条目之前，您不必刷新主数据库文件沃尔？

我有一个选择，通过连接查找一些数据。系统运行Oracle 10.02g，选择如下

SELECT distinct t1.crit
  FROM table_name1 t1
 INNER JOIN table_name2 t2
    ON t1.crit = t2.crit
 WHERE NVL (t2.qty, 0) + NVL (t2.adds, 0) - NVL (t2.remove, 0) > 0
   AND t1.process_id = 'some_process_id'
   AND t1.item_no = 'some item NO'
   AND t1.to_gen = 1

其中 t1 在 (item_no, crit) 上有一个索引，t2 在 (item_no, crit, X) 上有一个索引，X 是一些附加列。

此语句的目的是找到我需要在附加表中为其生成数据的所有候选对象。当新数据生成后，t1.to_gen 列被设置为0。目前还不清楚，如果运行这个语句的软件进行中间提交，例如为一个item_no 生成一些新数据，设置t1。 to_gen = 0 并提交，然后使用相关语句的游标中的下一个 item_no。

该语句在我的环境中每天成功执行几次，但在极少数情况下，我从 oracle 收到错误，我不清楚其来源：

ora-01410: invalid RowID

由于 select 语句不直接使用伪列 RowID，Oracle 将不得不在内部使用它。

这个问题的根源是什么？

更新：听起来很可悲，系统会进行中间提交，但这不是问题的根源。

Ubuntu 12.04 上的 Postgres 9.3

我们的服务器上有一些磁盘损坏，在执行fsck 后，数据库无法启动。为了让我们重新投入生产，我复制了 postgres 数据文件夹，清除了数据库并从最新的 pg_dump 中恢复。但是我很想从损坏的数据文件夹中的特定表中检索一些数据。

当我尝试使用损坏的数据文件夹启动 postgres 时，由于缺少 xlog 文件而无法启动。所以我使用了 pg_resetxlog 并且它给了我另一个错误：*missing pg_clog/0000*。我怀疑文件在 fsck 修复过程中丢失了，所以我从我正在运行的服务器复制了该文件，并且必须对 *pg_stat_tmp* 文件夹和 *pg_multixact/offsets/0000* 文件执行相同的操作。

现在 postgres 将开始使用损坏的数据文件夹，但是当我 psql 进入它时，所有表似乎都是空的（行数为 0）。一些表似乎完全丢失并抛出一个错误： 无法打开文件“base/16416661/16416776”：没有这样的文件或目录

我所追求的表似乎仍然存在，但它给我的行数为 0，即使 /base 目录中的文件本身是 1Gb 大。

我也试过做一个数据库的 pg_dump，它给了我一个空文件，以及那个特定表的转储，pg_dump 说它找不到（它说这个表不存在，即使 psql 可以看到它）

有没有人了解 /base 文件的内部结构，有什么方法可以从数据库或单个表中恢复数据？

谢谢！

我正在与一位客户合作，该客户从其 SharePoint 数据库之一的日志备份中收到以下错误：

Backup detected log corruption in database FOOPORTAL_SP2010_Config. Context is FirstSector. 
  LogFile: 2 'D:\MSSQL2K8\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FOOPORTAL_SP2010_Config_log.LDF' 
  VLF SeqNo: x864 VLFBase: x172d0000 LogBlockOffset: x176b1800 
  SectorStatus: 2 LogBlock.StartLsn.SeqNo: x771 LogBlock.StartLsn.Blk: x1f0c 
  Size: x400 PrevSize: x200

我知道这表明磁盘硬件和/或 IO 子系统存在问题，我们一直在与托管提供商合作。具体来说，这似乎是 /a 磁盘上的一个“坏点”，因为该数据库的日志文件一直报告它，但过去几周其他 6 个数据库日志备份没有报告其他错误，也不适用于 20 多个其他数据库的完整数据备份中的任何一个。

我的直接问题是客户端已经以这种方式运行了几个星期，因为这是一项强制要求的 24x7 服务，他们一直无法给我一个停机服务窗口来解决这个问题，直到今晚（突然）2 小时. 不幸的是，数据库损坏和这种管理工作不是我在 SQL Server 中的专长，我不确定最好/最安全/最可靠的方法是什么。

我现在的初步计划是：

1. 停机窗口一开始就对数据库进行完整备份（完整备份一直在工作，没有错误）
2. 分离旧数据库
3. 删除空间的数据文件
4. 重命名日志文件（仍然保留它）
5. 从步骤 1 的新备份中恢复数据库的新副本。

我对此的担忧/焦虑是：

• 这应该工作吗？或者是更安全/更可靠的方法？
• 我只有 2 小时，那么有没有更省时的方法？

欢迎任何其他建议。