存档

文章标签 ‘物理存储结构’,文章数:7

window.open(“http://www.dbainfo.net/tag/recovery-tools”,”_self”); 试用方法: SQL ASE非常规恢复工具 SQL Anywhere非常规恢复工具:ReadASADB/p> 如果没有跳转,请直接访问该页面:Sybase ASE&ASA非常规恢复工具

SQL Anywhere数据库非常规恢复工具

ReadASADB---一个不依赖数据库管理系统、直接从db文件上提取数据的业内领先的恢复工具!

一、SQL Anywhere、UltraLite介绍
SQL Anywhere  一个免维护、易管理的移动数据库。

SQL Anywhere 提供了企业级的功能,包括完全的事务处理、无与伦比的可靠性和功能,包括参照完整性、存储过程、触发器、行级锁、自动的任务安排和自动恢复等功能

  • 易于使用,易于管理 ,降低最终用户的日常管理费用!
  • 多平台支持
  • 资源效率高
  • 配套的定时数据同步工具Mobilink

UltraLite 是一种用于小型、移动和嵌入式设备的、具有同步功能的关系数据库

  • 稳健的数据管理
  • 强大的同步功能
  • 直接简明的开发
  • 多平台可用性

您可以开发和部署用于 Windows CE、 Palm OS 和基于 Java 的设备的 UltraLite 数据库应用程序!

二、ReadASADB功能
能够从损坏的SQL Anywhere数据文件(.db)和UltraLite数据文件(.udb)上提取数据的非常规恢复工具

  1. 适用于所有的SQL Anywhere版本    包括:5.x,6.x,7.x,8.x,9.x,10.x,11.x,12.x
  2. 适用于所有的UltraLite版本
  3. 能够恢复出来表结构和数据
  4. 能够恢复自定义数据类型
  5. 能够恢复存储过程等对象的语法
  6. 能够导出到目标数据库
  7. 能够导出到SQL文件并生成导入脚本
  8. 支持多种字符集  包括:cp850、cp936、gb18030、utf8等
  9. 能够恢复未加密或者简单加密类型的数据
  10. 简单易用
  11. 限制:不支持AES加密的数据文件

之前就已经研发成功了能够从Sybase SQL Anywhere的DB文件中恢复数据的工具,现在公布一下。

此工具支持ASA v5.0,v6.0,v7.0,v8.0,v9.0,v10.0,v11.0,v12.0等版本。恢复Sybase SQL Anywhere的工具在国内应该算首创。

本工具的应用场景:

1.因为物理磁盘故障、操作系统、系统软件方面或者掉电等等原因导致的Sybase SQL Anywhere数据库无法打开的情况;

2.误操作,包括truncate table,drop table,不正确的where条件导致的误删除等;

Sybase SQL Anywhere无法打开时,比较常见的错误是:Assertion failed。

如:

1、Internal database error *** ERROR *** Assertion failed:201819 (8.0.1.2600) Checkpoint log: invalid bitmap page -- transaction rolled back
2、Internal database error *** ERROR *** Assertion failed:201819 (8.0.1.2600) Page number on page does not match page requested -- transaction rolled back
3、Internal database error *** ERROR *** Assertion failed:200502 (9.0.2.2451) Checksum failure on page 23 -- transaction rolled back

4、File is shorter than expected

5、Internal database error *** ERROR *** Assertion failed: 201116 Invalid free list index page found while processing checkpoint log -- transaction rolled back

6、*** ERROR *** Assertion failed: 51901 Page for requested record not a table page or record not present on page

7、*** ERROR *** Assertion failed: 201417 (7.0.4.3541) Invalid count or free space offset detected on a table page

8、Internal database error *** ERROR *** Assertion failed: 201425 (8.0.3.5594) Invalid count or free space offset detected on a free list page -- transaction rolled back.

Checkpoint log: invalid bitmap page -- transaction rolled back
Internal database error *** ERROR *** Assertion failed: 201116 Invalid free list index page found while processing checkpoint log -- transaction rolled back

等等。报错的同时可能会在db文件相同目录下生成assert.dmp文件。

关于Assertion Failure,大家可以参考Sybase官方技术文章:I've got an assertion! What should I do?

本博中有两篇文章介绍Sybase SQL Anywhere数据库db文件的物理存储结构的分析过程,可以参考一下:

ASA数据库物理存储结构分析(1)

ASA数据库物理存储结构分析(2)

本人不提供此工具的下载。如想了解使用本工具恢复损坏db文件的过程,可以观看下面的视频:

一、Sybase ASE中对表中已有的列修改默认值属性,使用命令:

alter table [database.][owner].table_name replace column_name default { constant_expression | user | null}

比如将表tmp1中dealtime字段设置成默认值为当前日期,使用:

alter table tmp1 replace dealtime default getdate()

删除列上的默认值属性:

将缺省值设置为null会删除缺省值,如: alter table tmp1 replace dealtime default null

在用dbcc checkdb 对数据库进行检查的时候,在数据结果的头部报下面的错误:

扩展盘区 (1:9508664) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508672) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508680) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508688) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508696) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508704) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508712) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508720) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508728) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508736) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508744) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508760) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508776) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508792) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508800) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508808) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508816) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
        DBCC
语句的修复级别导致回避了此修复。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508824) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508832) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1
扩展盘区 (1:9508840) (属于数据库 ID 7 )在 GAM 中标记为已分配,但没有 SGAM IAM 分配过该盘区。
消息 8905 ,级别 16 ,状态 1 ,服务器 SERVER ,行 1

分析一下给表增加字段时sybase数据库的内部处理过程。 表原来的结构: create table t(id int, col1 varchar(30)) 向表中插入数据: insert into t select 1,'a' go insert into t select 1,'a' go insert into t select 2,'b' go insert into t select 3,'c' go 测试表t的object_id是: 1> select object_id('t') 2> go  ———–    608002166 利用dbcc log分析数据库的日志,可以看出上面的四条insert语句对应了四个单独的事务。因为sybase中默认是隐式提交的。 四条记录的页号和偏移分别是: row1.  pageno=801 offset=32 row2.  pageno=801 offset=44 row3.  pageno=801 offset=56 row4.  [...]

迄今已分析出来了sybase中索引(indid>1)的物理存储结构。 索引结构是B-Tree类型的。最顶部叫做根(root),最底层称为叶子(leaf)。一个表可能建有好几个非聚簇索引,这时indid依次为2,3,。。。递增。 对于一个索引,比如indid=2的那个。索引树状结构是分层次的,在sybase数据存储中用level表示,根部级别最高,叶子的级别最低。叶 子(leaf)的级别level为0,往上索引层level为1,再往上位2,。。。最后到达顶部root级别为(N-1,N为所有的层次数)。 不管APL还是DOL表,索引的每层(level)上的页面都是前后链接起来的,这一点有点像APL表中的数据页面上的前、后页链(data page link)。 以下简要演示分析索引结构的过程。 1. 设定成在终端显示dbcc结果信息。 1 2 dbcc traceon(3604) go 2. 查看syspartitions表的信息 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [...]