SAPSYBASEASE数据库备份还原手册zsq.docx

SAP ASE数据库备份还原手册SAP ASE数据库备份还原手册版本：v 0.1编辑：CNSAP.cn审核：日期：2015年6月19日目录一、制定备份和恢复计划41.关于数据库事物42.指定备份的职责43.安排例行备份44.在其它时间备份数据库55.安排 master 的备份56.截断 master 数据库事务日志57.保存脚本和系统表58.配置 Adaptive Server 以用于同时装载6二、备份数据库71.指定数据库名的规则72.压缩转储73.装载压缩转储84.设备出现故障后复制日志95.截断日志9三、恢复数据库101.获取事务日志的当前转储102.检查空间使用情况103.删除数据库114.重新创建数据库115.装载数据库116.装载事务日志117.装载事务日志到某个时间点118.使数据库处于联机状态12四、恢复系统数据库131.恢复过程总结132.恢复 master 数据库143.建立新的主设备144.在主恢复方式下启动 Adaptive Server155.重新创建 master 的设备分配156.检查 Backup Server sysservers 信息167.检验 Backup Server 是否在运行168.更新 number of devices 配置参数169.在主恢复方式下重新启动 Adaptive Server1710.检查系统表以检验 master 的当前备份1711.重新启动 Adaptive Server1712.恢复服务器用户 ID1713.检查 Adaptive Server1814.使用 disk reinit 恢复 sysdevices18五、DUMP命令详解191.dump database192.dump transaction24六、LOAD命令详解311.load database312.load transaction35七、备份还原示例391.dump database392.dump transaction413.load database424.load transaction43一、 制定备份和恢复计划Adaptive Server 具有自动恢复过程,可以使用户避免由于断电和计算机故障所造成的损失。若要避免介质故障带来损失,请定期经常对数据库进行备份。1. 关于数据库事物Adaptive Server 使用事务来跟踪数据库的所有变化。事务是 Adaptive Server 的工作单元。一个事务包括一个或多个作为一个单元成功或失败的 Transact-SQL 语句。 每条修改数据的 SQL 语句都被视为一个事务。通过将一系列语句放在 begin transaction.end transaction 块中,用户也可以定义事务。 每个数据库都拥有自己的事务日志,即系统表 syslogs 。事务日志自动记录每个数据库用户发出的每个事务。不能关闭事务记录。 事务日志是前写式日志。当用户发出要修改数据库的语句时, Adaptive Server 将这些更改写入日志中。在这条语句要做的所有更改都已记录在日志中后,这些更改将被写入到数据页的高速缓存副本中。此数据页将一直保留在高速缓存中,直到另一数据库页需要内存为止。那时,已更改的数据页才写入磁盘中。 如果事务中任何语句未能完成执行, Adaptive Server 将撤消由该事务所引起的所有更改。 Adaptive Server 在每个事务结束时将一条“end transaction”记录写入日志,记录该事务的状态 (成功或失败)。2. 指定备份的职责许多组织都有一位执行所有备份和恢复操作的操作员。只有系统管理员、数据库所有者或操作员才可以执行 dump 和 load 命令。数据库所有者只能转储自己的数据库。操作员和系统管理员可以转储和装载任何数据库。3. 安排例行备份开发备份计划中的主要任务是确定备份数据库的频率。备份频率决定在介质出现故障时丢失的工作量。创建每个用户数据库之后立即转储它以提供基点,并且以后按固定的时间表进行。推荐至少要每天备份事务日志,每周备份数据库。 许多拥有大型、活动数据库的安装每天转储数据库,并且每半个小时或每小时进行一次事务日志转储。 在没有跨数据库数据修改活动期间,应同时备份互依数据库 (其中存在跨数据库事务、触发器或参照完整性的数据库)。如果其中一个数据库失败并且需要重新装载,则从所有这些同时转储中重新装载它们。4. 在其它时间备份数据库除了定期转储以外,每次升级用户数据库、创建新索引、执行未记录的操作或者运行 dump transaction with no_log 或 dump transaction with truncate_only 命令时,也都要转储数据库。将用户数据库升级到当前版本的 Adaptive Server 后,转储最近升级的数据库,以便创建与当前版本兼容的转储。 dump database 必须在允许执行 dump transaction 之前、在已升级的用户数据库上进行。向表中添加索引时,将在事务日志中记录 create index 。而在向索引页填充信息时, Adaptive Server 却不记录这些更改。如果在您创建完索引后数据库设备出现故障,则使用 load transaction 命令重建索引所用时间可能与使用 create index 命令建立索引所用时间一样多。为避免长时间的延迟,需在数据库的一个表上创建索引后立即转储每个数据库。dump transaction with truncate_only 和 dump transaction with no_log 将从日志中删除事务而不进行备份。为确保可恢复性,请在每次由于磁盘空间不足而运行任一命令时转储数据库。这样做之后,才能复制事务日志。5. 安排 master 的备份master 数据库备份用作恢复过程的一部分,以防出现影响 master 数据库的故障。如果没有 master 数据库的当前备份,则可能在需要用户数据库并再次运行它时不得不重建重要的系统表。在执行影响磁盘、存储、数据库或段的每个命令后,都备份 master 数据库。始终在发出以下任何命令或系统过程后备份 master 数据库: disk init 、 sp_addumpdevice 或 sp_dropdevice 磁盘镜像命令 段系统过程 sp_addsegment 、 sp_dropsegment 或sp_extendsegment create procedure 或 drop procedure sp_logdevice sp_configure create database 或 alter database6. 截断 master 数据库事务日志 因为 master 数据库事务日志与数据存储在相同数据库设备上,所以不能单独备份其事务日志。不能移动 master 数据库的日志。必须经常使用 dump database 备份 master 数据库。定期使用具有truncate_only 选项的 dump transaction (例如,每次数据库转储后)清除 master 数据库的事务日志。7. 保存脚本和系统表 为进一步进行保护,保存包含所有 disk init 、 create database 和 alter database 命令的脚本,并在每次发出这些命令之一后为sysdatabases 、 sysusages 和 sysdevices 表生成书面副本。 您无法使用 dataserver 命令自动恢复这些命令导致的更改。如果您保留脚本 (包含 Transact-SQL 语句的文件),则可以运行它们以重新创建这些更改。或者,您必须针对重新构建的 master 数据库重新发出每个命令。 保留 syslogins 的书面副本。从转储中恢复 master 时,将表的书面副本与当前版本进行比较,以确保用户保持相同的用户 ID。8. 配置 Adaptive Server 以用于同时装载Adaptive Server 可以同时执行多个 load 和 dump 命令。装载数据库要求有一个 16K 缓冲区来用于每个活动数据库装载。缺省情况下, Adaptive Server 被配置为可同时进行六个装载。要同时执行多项装 载,系统管理员可以增加大型 I/O 缓冲区的数量: sp_configure "number of large i/o buffers", 12 此参数要求您重新启动 Adaptive Server。这些缓冲区不用于 dump 命令或 load transaction 命令。二、 备份数据库经常定期备份是防止由于数据库设备出现故障而损坏数据库的唯一方法。dump database 、 dump transaction 、 load database 和 load transaction 命令具有相似的语法。例行转储和装载要求数据库名和至少一个转储设备。这些命令还可包括下列选项: compression= ,用于将转储文件压缩为本地文件 at server_name ,用于指定远程 Backup Server density 、 blocksize 和 capacity ,用于指定磁带存储特性 dumpvolume ,用于指定 ANSI 磁带标签的卷名 file = file_name ,用于指定要转储到的或要从其装载的文件的名称 stripe on stripe_device ,用于指定其它转储设备 dismount 、 unload 、 init 和 retaindays ,用于指定磁带的处理操作 notify ,用于指定是将 Backup Server 消息发送到启动转储或装载的 client ,还是发送到 operator_console如果设备上的可用空间不足,无法成功发出 dump transaction 或dump transaction with truncate_only 命令,请使用 dump transaction with no_log 。1. 指定数据库名的规则 可以将数据库名以文字、局部变量或参数的形式指定给某一存储过程。 如果从转储中装载数据库: 此数据库必须存在。可以使用 create database 的 for load 选项创建一个数据库,或通过装载覆盖一个现有数据库。装载数据库始终会覆盖现有数据库中的所有信息。 使用的数据库名不必与所转储的数据库的名称相同。例如,您可以转储 pubs2 数据库,创建另一个名为 pubs2_archive 的数据库,然后将转储装载到新数据库中。2. 压缩转储 dump 命令包括两个选项,利用这两个选项,您可以使用 Backup Server 压缩数据库和事务日志,从而减少已存档数据库的空间要求。 参数为: compression = compression_level 压缩至远程服务器。导致Backup Server 使用其自己的本机压缩方法。Sybase 建议使用此压缩选项。 compress:compression_level: 压缩至本地文件。导致 Backup Server 调用外部过滤器,支持此选项是为了向后兼容。 compression_level 可以是 0 到 9 之间的某个数字,也可以是 100 或101。对于一位数的压缩级别,0 表示不压缩,9 表示压缩级别最高。 压缩级别 100 和 101 表示压缩比较速、高效,其中压缩级别 100 表示压缩速度较快,101 表示压缩性能较好。利用 dump 命令的 compression= 参数,可以减少已存档数据库的空间要求。使用 Adaptive Server 12.5.2 及更高版本,可以通过 compression= 参数将转储压缩到远程计算机。 如果使用旧的 compress: 选项,装载数据库转储时不需要包括压缩级别。但是,可以发出 load with listonly=full 命令以确定进行转储的压缩级别。 如果您使用本机 compression= 选项,则当装载数据库转储时,不需要包括 compression= 选项。 例如,若要将 pubs2 数据库转储到文件“compress_file”中,请输入: dump database pubs2 to compress_pression=100SAP建议您根据性能要求选择一组压缩级别。对于占用 CPU 时间不太多的压缩,请使用压缩级别 100 并根据存档空间要求切换至级别 101。对于常规压,请使用压缩级别 6,然后根据性能要求增高或降低级别。3. 装载压缩转储如果使用 dump . compress: 来转储数据库或事务日志,则必须使用load . compress: 选项来装载该转储。 load database . compress: 和 load transaction . compress: 的部分语法为: load database database_name from compress:stripe_device .stripe on compress:stripe_device. load transaction database_name from compress:stripe_device .stripe on compress:stripe_device. 语法中的 database_name 表示您存档的数据库, compress: 调用已存档数据库或事务日志的解压缩。archive_name 是您要装载的已存档数据库或事务日志的完整路径。如果创建转储文件时未包括完整路径, 则 Adaptive Server 将在启动 Adaptive Server 的目录中创建转储件。 如果使用 compress: 选项,则对于每个转储设备,它必须是 stripe on 子句的一部分。如果您使用compression= 选项,则在设备列表之后使用它一次。4. 设备出现故障后复制日志通常, dump transaction 在复制日志后截断日志的不活动部分。使用with no_truncate 可以在不截断日志的情况下复制日志。5. 截断日志在事务日志非常满时,您可能无法使用常规方法来转储它。如果使用了 dump transaction 或 dump transaction with truncate_only ,并且该命令由于日志空间不足而失败,请使用 dump transaction 的 with no_log 选项: dump transaction database_name with no_log 此选项截断日志,而不记录转储事务事件。因为此选项不复制任何数据,所以它只要求数据库的名称。警告:with truncate_only 和 with no_log 允许您截断可用空间极其不足的日志。这两个选项都无法恢复自上次例行转储后已提交的事务。三、 恢复数据库介质出现故障时的状况因故障原因的不同而异。如果磁盘上仅有一个块损坏,那么,除非您经常运行 dbcc 命令,否则,在损坏发生后, 数据库看上去会正常运行一段时间。如果整个磁盘或磁盘控制器损坏。Adaptive Server 将该数据库标记为可疑数据库并显警告消息。如果存储 master 数据库的磁盘出现故障,则用户将无法登录到服务器, 已登录的用户将无法执行需要访问 master 中的系统表的任何操作。当数据库设备出现故障时,SAP 会建议您执行下列步骤: 1 获取设备上每个数据库的当前日志转储。 2 检查设备上每个数据库 的空间使用情况。 3 在为设备上的所有数据库收集了这些信息之后,删除每个数据库。 4 使用 sp_dropdevice 删除有故障的设备。 5 使用 disk init 初始化新数据库设备。 6 重新创建数据库,一次创建一个。 7 将最新的数据库转储装载到每个数据库中。 8 按各个事务日志转储的创建顺序应用这些转储。1. 获取事务日志的当前转储使用 dump transaction with no_truncate 为出故障设备上的每一数据库获取当前事务日志转储。例如,若要获取 mydb 的当前事务日志转储, 请输入: dump transaction mydb to "/dev/nrmt0" at REMOTE_BKP_SERVER with init, no_truncate, notify = "operator_console"2. 检查空间使用情况检查和记录所有损坏的数据库的设备分配: 在 master 中,检查损坏的数据库的设备分配和使用情况: select segmap, size from sysusages where dbid = db_id("database_name") 检查查询的输出。每个 segmap 为 3 的行都表示数据分配。每个segmap 为 4 的行都表示日志分配。较高的值指示用户定义的段; 将这些段作为数据分配处理,以保留这些段的作用域。 size 列指 示数据块的数目。记录每一磁盘区段的顺序、用途和大小。3. 删除数据库在您为出现故障的设备上的所有数据库执行了前面所述的步骤后, 使用 drop database 删除每一数据库。如果当您发出 drop database 时,系统由于数据库受损而报告错误, 请使用: dbcc dbrepair (mydb, dropdb)4. 重新创建数据库将 create database 与 for load 选项一起使用。从 sysusages 表中复制数据库的每个行的所有设备段映射和大小,直到第一个日志设备(包括该设备)。以这些行在 sysusages 中出现的顺序使用它 们。( sp_helpdb 的结果按设备名的字母顺序排列,而不是按分配顺序排列。)将 alter database 与 for load 选项一起使用以按顺序重新创建其余 的条目。请记住,应像您处置数据分配一样为用户段处置设备 分配。5. 装载数据库 使用 load database 重装数据库。如果原始数据库在用户定义的段上 存储了对象( sysusages 报告 segmap 大于 7),并且您的新设备分配 匹配转储的数据库的设备分配,则 Adaptive Server 保留用户段映射。 如果您没有创建新设备分配以匹配转储的数据库的设备分配,则 Adaptive Server 会将段重新映射到可用的设备分配。此重新映射还 混合同一物理设备上日志和数据。6. 装载事务日志 使用 load transaction 以事务日志备份的生成顺序应用事务日志备份。 Adaptive Server 检查每一转储的数据库和事务日志上的时间戳。如果 转储以错误顺序装载,或者用户事务在两次装载之间修改了事务日 志,则装载将失败。 如果您使用 with standby_access 转储了事务日志,则也必须使用 standby_access 装载数据库。 在您使数据库处于最新状态后,使用 dbcc 命令检查其一致性。7. 装载事务日志到某个时间点 您可以恢复数据库,一直恢复到其事务日志中某个指定的时间点。 为此,请使用 load transaction 的 until_time 选项。例如,在用户无意 中删除了某个重要的表的情况下可以使用这一选项;您可以使用 until_time 将对包含该表的数据库进行的更改一直恢复到刚删除该表 之前那一时刻的状态。 为了在数据已被损坏后有效使用 until_time ,您必须知道发生错误的 确切时间。您可以通过在出现错误时发出 select getdate 来找到这一 时间。例如,假定用户无意中删除了一个重要的表,然后在几分钟 之后您以毫秒为单位获取当前时间: select convert(char(26), getdate(), 109)8. 使数据库处于联机状态 将所有事务日志转储应用到数据库之后,使用 online database 使其 可供使用。例如,若要使 mydb 数据库联机,请输入: online database mydb四、 恢复系统数据库系统数据库的恢复过程取决于所使用的数据库和系统中出现的问题。 通常,恢复可能包括: 使用 load database 装载这些数据库的备份, 使用 dataserver 、 installmaster 和 installmodel 恢复这些数据库的初始状态,或 这些任务的组合。 要使系统数据库的恢复尽可能高效地进行: 不要在主设备上存储用户数据库或除 master 、 tempdb 、 model 和sybsystemdb 以外的任何其它数据库。 始终保存重要系统表的最新打印输出。 每次执行初始化数据库设备、创建或变更数据库或添加新的服务器登录名等操作之后,都要备份 master 数据库。1. 恢复过程总结 必须遵循以下步骤来恢复损坏的主设备。 1 查找恢复磁盘、数据库和登录名所需的系统表的书面副本。 2 关闭 Adaptive Server,并使用 dataserver 构建新 master 数据库和主设备。 3 以主恢复方式重新启动 Adaptive Server。 4 在 sysusages 中正确地重建 master 数据库的分配。 5 更新 sysservers 表中 Backup Server 的网络名。 6 检验 Backup Server 以确保其正在运行。 7 使用 load database 装载 master 的最新数据库转储。成功装载master 后,Adaptive Server 将自动停止。8 在配置文件中更新 number of devices 配置参数。 9 在单用户模式下重新启动 Adaptive Server。 10 检验 master 的备份是否拥有最新的系统表信息。 11 重新启动 Adaptive Server。 12 如果自上次备份 master 后添加了新的登录名,则检查 syslogins 。 14 恢复 model 数据库(如果需要)。 14 将 sysusages 和 sysdatabases 的书面副本与新的联机版本进行比较,针对每个数据库运行 dbcc checkalloc ,并检查每个数据库中的重要表。 15 转储 master 数据库。2. 恢复 master 数据库 受损的 master 数据库可能是由存储 master 的区域中的介质故障导致, 也可能是由数据库的内部损坏导致。如果出现以下情况,将会损坏master 数据库: Adaptive Server 不能启动。 出现频繁或破坏性的分段故障错误或输入/输出错误。 dbcc 在定期检查数据库期间报告损坏。 假定: master 数据库已损坏,或主设备已损坏。 您拥有系统表的最新输出,“系统及可选数据库”列出了这些输出。 主设备只包括 master 数据库、 tempdb 、 model 和 sybsystemdb 。 您拥有 master 数据库的最新备份,并且,自上次转储 master 以来,您尚未初始化任何设备,也未创建或修改任何数据库。 您的服务器使用缺省排序顺序。3. 建立新的主设备 仅当旧的主设备的损坏无法修复时,才应构建新的主设备。否则, 您可以在现有主设备上重新创建 master 和 model 数据库。 重新创建 master 数据库有两个过程:替换主设备,并强制 Adaptive Server 重新创建配置区域。当 master 数据库损坏时替主设备。如果主设备的配置区域也损坏,请强制 Adaptive Server 重新创建配置区域。您可以经常检测配置区域是否由于服务器无法运行而损坏,并生成错误消息来指明该区域已损坏。 以下示例使用 UNIX 的 dataserver 命令。在 Windows 平台上,使用sqlsrvr 命令。 替换主设备 用 dataserver -w 选项重建主设备: dataserver -w master 重建配置区域 如果配置区域损坏,则必须使用 -f 选项强制 Adaptive Server 重建该区域。但有以下限制: 如果页大小错误,则您可以指定页大小(例如, -z8k )。 如果设备大小错误,则您可以指定设备大小(例如, -b125M ) 磁盘上显示为损坏或当前未分配的所有分配单元都将分配给master 数据库。带或不带 -f 的 -w master 选项仅重新创建 master 数据库。磁盘上的所有其它分配单元保持不变,因此,您可以使用 disk refit 恢复数据。 如果整个主设备已损坏(例如,如果磁盘发生故障),请通过使用dataserver -zpage_size. .-bdevice_size 启动 Adaptive Server 来更换整个设备: 1 如果现有主设备不在原始分区上,并且您打算重新使用该设备, 请删除旧的主设备文件。 2 使用 dataserver -zpage_size. .-bdevice_size 启动服务器。4. 在主恢复方式下启动 Adaptive Server 使用 -m (UNIX 和 Windows)选项在主恢复方式下启动 Adaptive Server。 在 UNIX 平台上,复制 runserver 文件,并将其命名为m_RUN_server_name。编辑该新文件,在 dataserver 命令行添加参数 -m 。然后在主恢复方式下启动服务器: startserver -f m_RUN_server_name 在 Windows 平台上 从命令行使用 sqlsrver 命令启动 Adaptive Server。除其它必要的参数外,指定 -m 参数。例如: sqlsrver.exe -dD:SybaseDATAMASTER.dat -sPIANO -eD:Sybaseinstallerrorlog -iD:Sybaseini -MD:Sybase -m在主恢复方式下启动 Adaptive Server 时,只允许使用一个用户(系统管理员)的一个登录名。5. 重新创建 master 的设备分配 如果您根据上面步骤 2 中描述的过程重新创建了主设备,则您的master 数据库现在可能太小。为 master 数据库分配更多空间: 从 sysusages 的书面副本中,对为 dbid 1 ( master 数据库的 dbid ) 显示的 size 值求和。将这些值与当前 master 数据库的大小进行比较。您可以通过发出以下命令来确定它们: select sum(size) from sysusages where dbid = 1如果当前的 master 数据库太小,请使用 alter database 将它扩大至所需的大小。若要将逻辑页转换为 MB 级页,请使用: select N / (power(2,20) / maxpagesize) 其中 N 是逻辑页的数量。 如果使用 -m master 选项重新编写了 master 数据库,则不必更改master 数据库的大小。由于 Adaptive Server 已记录了设备上所有数据库使用的分配单元,因此,您应该已有足够的空间装载 master 的转储。6. 检查 Backup Server sysservers 信息 以“sa”身份登录服务器。 如果 Backup Server 的网络名称不是 SYB_BACKUP,请更新sysservers ,以便 Adaptive Server 可以与其 Backup Server 进行通信。 在接口文件中检查 Backup Server 名称,然后发出: select * from sysservers where srvname = "SYB_BACKUP"如果报告的 srvnetname 与接口文件中的 Backup Server 不同,请更新 sysservers 。下例将 Backup Server 的网络名更改为 PRODUCTION_BSRV: begin transaction update sysservers set srvnetname = "PRODUCTION_BSRV" where srvname = "SYB_BACKUP" 执行此命令,并验证它是否仅修改了一行。重新发出 select 命令, 然后核实是否修改了正确的行,该行是否包含正确的值。如果 update 修改了多行,或者修改了不应修改的行,则应发出 rollback transaction 命令,然后尝试再次更新。 如果该命令正确地修改了 Backup Server 的行,则应发出 commit transaction 命令。7. 检验 Backup Server 是否在运行 在 UNIX 平台上,使用 showserver 命令核实 Backup Server 是否正在运行;如果必要,重新启动 Backup Server。装载 master 的备份 装载 master 数据库的最新备份。 例如,在 UNIX 平台上,使用: load database master from "/dev/nrmt4"在 load database 成功完成之后,Adaptive Server 会关闭。注意在装载过程和关闭过程中是否有错误消息.8. 更新 number of devices 配置参数 仅当使用的数据库设备数比缺省值多时才执行此步骤。 除非恢复 master 数据库,否则 Adaptive Server 无法使用配置值,因此,请指示 Adaptive Server 在启动时从配置文件中读取适当的number of devices 参数值。 如果最新配置文件不可用,请编辑配置文件以反映 number of devices 参数的正确值。 编辑 runserver 文件。在 dataserver 或 sqlsrver 命令的末尾添加 -c 参数,以指定配置文件的名称和位置。Adaptive Server 启动时,将从指定的配置文件中读取参数值。9. 在主恢复方式下重新启动 Adaptive Server装载 master 的备份时,会使“sa”帐号恢复到先前的状态。如果“sa”帐户有口令,则恢复该口令。如果在进行备份之前使用sp_locklogin 锁定了此帐户,则“sa”帐户会立即锁定。将帐户与sa_role 配合使用来执行其余恢复步骤。10. 检查系统表以检验 master 的当前备份 如果在发出最新的 disk init 、 create database 或 alter database 命令后, 已备份了 master 数据库,则 sysusages 、 sysdatabases 和 sysdevices 的内容会与书面副本匹配。 依据书面副本,检查恢复后服务器中的 sysusages 、 sysdatabases 和sysdevices 表。尤其注意以下问题:如果书面副本中的设备有的未包括在已恢复的 sysdevices 中, 则自上次备份以来已经添加了设备,并且您必须运行 disk reinit 和 disk refit 。 如果书面副本中列出的数据库有的未包括在已恢复的sysdatabases 表中,则意味着自上次备份 master 以来添加了数据库。您必须运行 disk refit 。11. 重新启动 Adaptive Server 以常规(多用户)模式重新启动 Adaptive Server。12. 恢复服务器用户 ID 检查 syslogins 的书面副本和恢复的 syslogins 表。 如果自上次备份 master 以来已经添加了服务器登录名,请重新发出 create login 命令。 如果已删除了服务器登录名,则应重新发出 drop login 命令。 如果已锁定了服务器帐户,则应重新发出 sp_locklogin 命令。 检查由于用户或系统管理员使用 alter login 而引起的其它差别。 确保指派给用户的 suids 正确。数据库中不匹配的 suid 值会导致权限问题,用户可能不能访问表或运行命令。 检查现有 suid 值的有效方法是对用户数据库的每个 sysusers 表执行union 。如果用户有权使用 master ,则可以在此过程中包括 master 。 例如: select suid, name from master.sysusers union select suid, name from sales.sysusers union select suid, name from parts.sysusers union如果结果列表显示的已跳过的 suid 值介于您在其中恢复登录名的范围内,请为跳过的值添加占位符,然后使用 drop login 删除它们或者使用 sp_locklogin 锁定它们。13. 检查 Adaptive Server 仔细检查 Adaptive Server: 1 将 sysusages 的书面副本与新的联机版本进行比较。 2 将 sysdatabases 的书面副本与新的联机版本进行比较。 3 针对每个数据库运行 dbcc checkalloc 。 4 检查每个数据库中重要的表。14. 使用 disk reinit 恢复 sysdevices 如果自上次转储后添加了任何数据库设备,即如果发出了 di