如何恢复tempdb数据库

如何恢复tempdb数据库,第1张

1 停止 SQL Server。打开命令提示符,然后键入以下命令启动 SQL Server:

sqlservr -c -f

-c 和 -f 参数使 SQL Server 以最小配置模式启动,让数据文件的 tempdb 大小为 1 MB,日志文件的 tempdb 为 05 MB。

注意:如果使用 SQL Server 命名实例,必须切换到适当的文件夹 (Program Files/Microsoft SQL Server/MSSQL$instance name/Binn),并使用 -s 开关 (-s%instance_name%)。

2 用查询分析器连接到 SQL Server,然后运行下列 Transact-SQL 命令: ALTER DATABASE tempdb MODIFY FILE

(NAME = 'tempdev', SIZE = target_size_in_MB)

--Desired target size for the data file

ALTER DATABASE tempdb MODIFY FILE

(NAME = 'templog', SIZE = target_size_in_MB)

--Desired target size for the log file

3 通过在命令提示符窗口中按 Ctrl-C 停止 SQL Server,将 SQL Server 作为服务重新启动,然后验证 Tempdbmdf 和 Templogldf 文件的大小。

此方法的局限是它只能对默认的 tempdb 逻辑文件 tempdev 和 templog 进行 *** 作。如果将其他文件添加到了 tempdb,您可以在将 SQL Server 作为服务重新启动后收缩它们。在启动过程中将重新创建所有 tempdb 文件;因此,它们是空的并可删除。要删除 tempdb 中的其他文件,请使用带有 REMOVE FILE 选项的 ALTER DATABASE 命令。

如果没有主数据库,您就无法成功地启动SQL Server。在本文里,我将向您介绍在发生崩溃的情况下如何修复主数据库,并告诉您如何重建主数据库,如果有必要的话。

制定预案

制定一个应对崩溃和/或主数据库故障的预案十分重要。这将有助于您在碰到灾难的情况下按照既定的方法进行处理,而不是迫于压力仓促作出反应。我碰到过很多很容易就陷入惊慌的状况,但是由于保持冷静并按照正确的方法来处理问题,我最后成功地度过了所有的困境。

怎么才能知道您的主数据库已经崩溃?

在正式开始讨论碰到系统故障如何修复和重建的主数据库之前,我们需要先了解如何辨别它已经崩溃了。要说明这一点,我会弄垮一个主数据库,告诉您主数据库崩溃会发生什么样的症状。

现在让我们假设您的公司碰到了电涌,造成SQL Server重启。在重新启动的时候,SQL Server却没有正常启动。如果查看错误日志,您会看到主数据库崩溃或者丢失。既然您知道需要查看什么信息,那就让我们看看如何修复主数据库。

修复您的主数据库

修复主数据库的第一步是使用“重建向导(Rebuild Wizard,Rebuildmexe),它放在\Program Files\Microsoft SQL Server\80\Tools\BINN目录下。现在就让我们来看看重建向导是如何工作的。

双击Rebuildmexe启动对话框。

在这个对话框里,您可以指定数据库服务器的修复设置,以及原始安装的数据文件的位置。要让这一过程更容易和更快,就要把x86目录从SQL的光盘上复制到硬盘上,并把指向改到本地的副本。一旦验证完了所有的信息,点击“重建(Rebuild)”。然后系统就会提示您确认 *** 作

点击“确定(Yes)”。一旦重建过程完成,您会看到一条重建成功的消息。您现在就有了一个全新的主数据库,准备好修复主数据库了。

首先,打开命令行提示符,输入\Program Files\Microsoft SQL Server\MSSQL\BINN\目录下的sqlservrexe –c –m命令,启动单用户模式下的SQL Server。

在单用户模式下启动SQL Server之后,您可以利用备份文件修复主数据库。您可以用“查询分析器(Query Analyzer)”或者“SQL企业管理器(SQL Enterprise Manager)”来修复它。

如果使用企业服务器,就要右击主数据库,选择“所有任务|修复数据库(All Tasks | Restore Database)”,浏览到您设备所在的位置,点击两次“OK”,您就可以成功地修复主数据库了。

如果由于某种原因您的修复 *** 作无法成功完成,那么您可以试试别的方法。只用简单地重建主数据库并添加驻留在数据目录下的所有数据库就可以了。您可以用企业管理器或者查询分析器来添加数据库。在企业管理器里,右击“数据库(Databases)”,选择“添加数据库(Attach Database)”

1、选择开始菜单中→程序→management

sql

server

2008→sql

server

management

studio命令,打开sql

server

management

studio窗口,并使用windows或

sql

server身份验证建立连接。

2、在对象资源管理器窗口中展开服务器,然后选择数据库节点

3、右键单击数据库节点,从d出来的快捷菜单中选择新建数据库命令。

4、执行上述 *** 作后,会d出新建数据库对话框。在对话框、左侧有3个选项,分别是常规、选项和文件组。完成这三个选项中的设置会后,就完成了数据库的创建工作,

5、在数据库名称文本框中输入要新建数据库的名称。例如,这里以“新建的数据库”。

6、在所有者文本框中输入新建数据库的所有者,如sa。根据数据库的使用情况,选择启用或者禁用使用全文索引复选框。

7、在数据库文件列表中包括两行,一行是数据库文件,而另一行是日记文件。通过单击下面的添加、删除按钮添加或删除数据库文件。

8、切换到选项页、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

9、切换到文件组页,在这里可以添加或删除文件组。

10、完成以上 *** 作后,单击确定按钮关闭新建数据库对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再对象资源管理器窗口看到。

修复数据库坏块

dbv

你也可以用dbv工具看一下你现在其他的数据文件有没有还有坏块的

dbv file='yourfilename'

恢复方法:

当Oracle数据库出现坏块时,Oracle会在警告日志文件(alert_SIDlog)中记录坏块的信息:

ORA-01578: ORACLE data block corrupted (file # 7, block # )

ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01dbf'

其中,<AFN>代表坏块所在数据文件的绝对文件号,代表坏块是数据文件上的第几个数据块

出现这种情况时,应该首先检查是否是硬件及 *** 作系统上的故障导致Oracle数据库出现坏块。在排除了数据库以外的原因后,再对发生坏块的数据库对象进行处理。

1.确定发生坏块的数据库对象

SELECT tablespace_name,

segment_type,

owner,

segment_name

FROM dba_extents

WHERE file_id =

AND between block_id AND block_id+blocks-1;

2.决定修复方法

如果发生坏块的对象是一个索引,那么可以直接把索引DROP掉后,再根据表里的记录进行重建;

如果发生坏块的表的记录可以根据其它表的记录生成的话,那么可以直接把这个表DROP掉后重建;

如果有数据库的备份,则恢复数据库的方法来进行修复;

如果表里的记录没有其它办法恢复,那么坏块上的记录就丢失了,只能把表中其它数据坏上的记录取出来,然后对这个表进行重建。

3.用Oracle提供的DBMS_REPAIR包标记出坏块

exec DBMS_REPAIRSKIP_CORRUPT_BLOCKS('','');

4.使用Create table as select命令将表中其它块上的记录保存到另一张表上

create table corrupt_table_bak

as

select from corrupt_table;

5.用DROP TABLE命令删除有坏块的表

drop table corrupt_table;

6.用alter table rename命令恢复原来的表

alter table corrupt_table_bak

rename to corrupt_table;

7.如果表上存在索引,则要重建表上的索引

PART2

2014722研究恢复数据库坏块:

Oracle调用标准C的系统函数,对数据块进行读写 *** 作,因此,坏块是有可能由以下几种原因产生:

硬件的I/O错误

*** 作系统的I/O错误或缓冲问题

内存或paging问题

磁盘修复工具

一个数据文件的一部分正在被覆盖

Oracle试图访问一个未被格式化的系统块失败

数据文件部分溢出

Oracle或者 *** 作系统的bug

遇到“ORA-01578:ORACLE data block corrupted”错误

处理方法:1rman的recover命令可以在数据库保持open状态下只恢复受损的数据块

2如果没有备份,万不得已之下也可以采用DBMS_REPAIR包的存储过程将受损坏块隔离,同时尽可能地挽救部分数据。

rman backup命令也是检查坏数据块的好工具 一旦读取ORA-19566 即可有问题

此时可用backup validate tablespace user观察详细的信息,可查看到坏块数与跟踪文件

grep‘corrupt’/u01/app/oracle/diag/rdbms/br/br/trace/trc

恢复数据块:rman》recover datafile 5 block 203;

批量恢复受损的数据块:recover corruption list;

数据块坏块一号坏块,需要做:

run{

sql 'alter database datafile 5 offline';

restore datafile 5;

recover datafile 5;

sql'alter database datafile 5 online'

}

使用exp/imp恢复

在这种情况下肯定会造成数据的丢失,在这种情况下应采取将数据导出然后重建表再进行导入的方法,来尽量恢复损坏数据块中的数据,但是在有坏块的情况下是不允许导出的,如下命令:Exp test/test file=tdmp tables=t;

导出命令在执行中会报ORA-01578错误,在这错误提示中会提示那个文件号的文件以及这个文件中的哪个块被损坏,如:ORA—01578:ORACLE 数据块损坏(文件号 4,块号 35)

针对以上的提示首先查询那些对象被损坏:

Select tablespace_name,segment_type,owner,segment_name From dba_extents Where file_id=4 and 35 between block_id and block_id+blocks-1;

如果被损坏的块是索引,通常可以通过索引重建来解决,如果损坏的是数据(segment_type为table),那么通过设置如下内部事件使得Exp *** 作跳过坏块。

Alter session set events=’10231 trace name context forever,level 10’;

然后重新执行导出命令,导出相关的表,然后执行Drop Table命令删除相关表,之后重建表最后导入数据。

使用DBMS_REPAIR恢复

用DBMS_REPAIR当然也会丢失数据。这里不做详细的介绍,有兴趣的可以查看oracle的在线文

3、使用dbms_repair包进行坏块处理

1)首先建立repair_table,用于存放dbms_repaircheck_object检测出来的坏块信息

SQL> declare

2begin

3dbms_repairadmin_tables

4(table_name => 'REPAIR_TABLE',--表名

5table_type => dbms_repairrepair_table,

6action => dbms_repaircreate_action,

7tablespace => 'USERS');--用于指定该表存放的表空间

8end;

9/

PL/SQL 过程已成功完成。

SQL> col owner format a10

SQL> col object_name format a20

SQL> col object_type format a20

SQL> select owner, object_name, object_type

2from dba_objects

3where object_name like '%REPAIR_TABLE';

OWNEROBJECT_NAMEOBJECT_TYPE

---------- -------------------- --------------------

SYSREPAIR_TABLETABLE

SYSDBA_REPAIR_TABLEVIEW

Oracle自动创建了一个DBA_REPAIR_TABLE视图。

2)使用dbms_repaircheck_object进行坏块检测

SQL> set serveroutput on size 100000;

SQL> declare

2rpr_count int;

3begin

4rpr_count := 0;

5dbms_repaircheck_object(

6schema_name => 'SYS',--指定对象模式,也就是对象的所有者

7object_name => 'TEST',--指定对象名,也就是表名

8repair_table_name => 'REPAIR_TABLE',

9corrupt_count => rpr_count);

10dbms_outputput_line('repair block count: '

11||to_char(rpr_count));

12end;

13/

repair block count: 4

PL/SQL 过程已成功完成。

SQL> select object_name, block_id, corrupt_type, marked_corrupt,

2corrupt_description, repair_description

3from repair_table;

OBJECT_NAMEBLOCK_ID CORRUPT_TYPE MARKED_COR

-------------------- ---------- ------------ ----------

CORRUPT_DESCRIPTION

-------------------------------------------------------------------------------

REPAIR_DESCRIPTION

-------------------------------------------------------------------------------

TEST196148 TRUE

mark block software corrupt

TEST206148 TRUE

mark block software corrupt

TEST236148 TRUE

mark block software corrupt

TEST316148 TRUE

mark block software corrupt

通过运行dbms_repaircheck_object,将坏块信息存放到了repair_table表中,其中有个字段marked_corrupt,用于标识该块是否被标识为坏块,当被标识为true时,即该块被标识为坏块。其中这一步跟oracle文档中的描述有点进入,根据oracle文档,当执行完dbms_repaircheck_object时,并不会进行坏块标识,也就是marked_corrupt列的值应该为false,而只有当执行dbms_repairfix_corrupt_blocks过程后才会进行坏块标识。

3)使用dbms_repairfix_corrupt_blocks进行坏块标识

SQL> declare

2fix_block_count int;

3begin

4fix_block_count := 0;

5dbms_repairfix_corrupt_blocks (

6schema_name => 'SYS',

7object_name => 'TEST',

8object_type => dbms_repairtable_object,

9repair_table_name => 'REPAIR_TABLE',

10fix_count => fix_block_count);

11dbms_outputput_line('fix blocks count: ' ||

12to_char(fix_block_count));

13end;

14/

fix blocks count: 0

PL/SQL 过程已成功完成。

我们可以见到到fix blocks count=0,即在上一步进行check_object时已经进行了坏块标识了,这一步其实可以省略。(不过没有测试过!)

 

Linux, 环境, 数据库Linux, 数据库, 环境

通过如下备份脚本备份的数据库进行恢复

备份脚本:

 /home/db2admin/sqllib/db2profile  db2 backup db datedb online to /dbbackup/date include logs  cd /dbbackup/datetoday=`date +”%Y%m%d”`  file1=”$today”  ftpfile=`ls $file1`  echo $ftpfile  lftp -c “open ftp地址;user 用户名密码@\$0;put $ftpfile”  find /dbbackup/date -ctime +15 -exec rm {} \; 

恢复命令:

通过root命令登录到服务器上后切换到数据库用户名下用su – db2admin命令。

进入到备份文件存放目录即可。

蛙蛙推荐:利用WMI脚本批量恢复SQLSERVER数据库

问题提出

蛙蛙求助:以编程的方式还原sqlserver数据库问题

我有一个目录下面都是sqlserver的数据库备份文件,比如abak,bbak,cbak等,有没有办法一下把他们都还原到本地SQLSERVER数据库里面呀,过程是自动建立a,b,c这样的数据库,然后把abak恢复到a,bbak恢复到b,依次类推,因为备份文件的原路径和新库的路径不一样,所以要有一些额外处理,谁能解决一下,因为这个目录下有几十个库的备份文件呢,现在我的机器新安装了一个SQLSERVER,要把他们全部恢复,当时没有分离库,所以不能直接附加

设计方案

可以利用WMI脚本扫描存放数据库备份文件的目录,然后按照一定的规则生成一个恢复数据库的T-sql脚本文件,然后用脚本执行osql程序来执行这个脚本完成数据库恢复,这里没有使用过多的错误处理和事务的代码,因此要人为的确定数据库恢复的T-SQL语句尽量不要引发异常。

解决方案

一、我们先来看一下恢复数据库的T-SQL命令,以便理解后面通过脚本来创建T-SQL的原理

USE master

GO

--如果要创建的数据库已经存在,那么删除它

IF EXISTS (SELECT name FROM masterdbosysdatabases WHERE name = N'article')

DROP DATABASE [article]

GO

--创建一个新数据库,要指定新建数据库的数据文件和日志文件的名称和位置,初始化大小

--增长幅度,最大值等内容

CREATE DATABASE article

ON

( NAME = N'article_dat',

FILENAME = N'd:\sql2000\MSSQL\data\article_DataMDF',

SIZE = 1,

MAXSIZE = 50,

FILEGROWTH = 5 )

LOG ON

( NAME = N'article_log',

FILENAME = N'd:\sql2000\MSSQL\data\article_LogLDF',

SIZE = 1MB,

MAXSIZE = 25MB,

FILEGROWTH = 5MB )

GO

--把指定的数据库备份文件恢复到刚刚建立的数据库里,这里要指定数据库备份文件的位置

--以及要恢复到的数据库,因为备份文件来自未知的机器,备份的时候原数据库和新数据库

--的数据文件和日志文件的位置不匹配,所以要用with move指令来完成强制文件移动,如果

--是通过管理器备份的数据库文件,数据库文件和日志文件名分别是数据库名跟上"_Data"或

--"_Log",这是一个假设哦,如果不是这样,脚本有可能会出错

RESTORE DATABASE [article]

FROM DISK = 'E:\windowdatabase\articlebak'

WITH

MOVE 'article_Data' TO 'd:\sql2000\MSSQL\data\article_DataMDF',

MOVE 'article_Log' TO 'd:\sql2000\MSSQL\data\article_LogLDF'

GO

从中可以看到T-SQL的强大。

1 数据库的启动(STARTUP)

在Startup命令中,可以通过不同的选项来控制数据库的不同启动步骤。

1、STARTUP NOMOUNT

NONOUNT选项仅仅创建一个Oracle实例。读取initora初始化参数文件、启动后台进程、初始化系统全局区(SGA)。Initora文件定义了实例的配置,包括内存结构的大小和启动后台进程的数量和类型等。实例名根据Oracle_SID设置,不一定要与打开的数据库名称相同。当实例打开后,系统将显示一个SGA内存结构和大小的列表,如下所示:

SQL> startup nomount

ORACLE instance started

Total System Global Area 35431692 bytes

Fixed Size 70924 bytes

Variable Size 18505728 bytes

Database Buffers 16777216 bytes

Redo Buffers 77824 bytes

2、STARTUP MOUNT

该命令创建实例并且安装数据库,但没有打开数据库。Oracle系统读取控制文件中关于数据文件和redo log文件的内容,但并不打开这些文件。这种打开方式常在数据库维护 *** 作时使用,如对数据文件的更名、改变redo log以及打开归档方式、执行数据库的full database recovery。在这种打开方式下,除了可以看到SGA系统列表以外,系统还会给出" Database mounted "的提示。

3、STARTUP

该命令完成创建实例、安装实例和打开数据库的所有三个步骤。此时数据库使数据文件和redo log文件在线,通常还会请求一个或者是多个回滚段。这时系统除了可以看到前面Startup Mount方式下的所有提示外,还会给出一个" Database opened "的提示。此时,数据库系统处于正常工作状态,可以接受用户请求。

如果采用STARTUP NOMOUNT或者是STARTUP MOUNT的数据库打开命令方式,必须采用ALTER DATABASE命令来执行打开数据库的 *** 作。例如,如果你以STARTUP NOMOUNT方式打开数据库,也就是说实例已经创建,但是数据库没有安装和打开。这时必须运行下面的两条命令,数据库才能正确启动。

ALTER DATABASE MOUNT;

ALTER DATABASE OPEN;

而如果以STARTUP MOUNT方式启动数据库,则只需要运行下面一条命令即可以打开数据库:

ALTER DATABASE OPEN;

4、其他打开方式

除了前面介绍的三种数据库打开方式选项外,还有另外其他的一些选项。

(1) STARTUP RESTRICT

这种方式下,数据库将被成功打开,但仅仅允许一些特权用户(具有DBA角色的用户)才可以使用数据库。这种方式常用来对数据库进行维护,如数据的导入/导出 *** 作时不希望有其他用户连接到数据库 *** 作数据、数据装载、特定的迁移或者升级 *** 作等。

(2) STARTUP FORCE

该命令其实是强行关闭数据库(shutdown abort)和启动数据库(startup)两条命令的一个综合。该命令仅在关闭数据库遇到问题不能关闭数据库时采用。

(3) ALTER DATABASE OPEN READ ONLY;

该命令在创建实例以及安装数据库后,以只读方式打开数据库。对于那些仅仅提供查询功能的产品数据库可以采用这种方式打开。

2 数据库的关闭(SHUTDOWN)

对于数据库的关闭,有四种不同的关闭选项。

1、SHUTDOWN NORMAL

这是数据库关闭SHUTDOWN命令的确省选项。也就是说如果输入SHUTDOWN这样的命令,也就是执行SHUTDOWN NORNAL命令。

发出该命令后,任何新的连接都将再不允许连接到数据库。在数据库关闭之前,Oracle将等待目前连接的所有用户都从数据库中退出后才开始关闭数据库。采用这种方式关闭数据库,在下一次启动时不需要进行任何的实例恢复。但需要注意的是,采用这种方式,也许关闭一个数据库需要几天时间,或者更长。

2、SHUTDOWN IMMEDIATE

这是常用的一种关闭数据库的方式,想很快地关闭数据库,但又想让数据库干净的关闭,常采用这种方式。

当前正在被Oracle处理的SQL语句立即中断,系统中任何没有提交的事务全部回滚。如果系统中存在一个很长的未提交的事务,采用这种方式关闭数据库也需要一段时间(该事务回滚时间)。系统不等待连接到数据库的所有用户退出系统,强行回滚当前所有的活动事务,然后断开所有的连接用户。

3、SHUTDOWN TRANSACTIONAL

该选项仅在Oracle 8i后才可以使用。该命令常用来计划关闭数据库,它使当前连接到系统且正在活动的事务执行完毕,运行该命令后,任何新的连接和事务都是不允许的。在所有活动的事务完成后,数据库将和SHUTDOWN IMMEDIATE同样的方式关闭数据库。

4、SHUTDOWN ABORT

这是关闭数据库的最后一招,也是在没有任何办法关闭数据库的情况下才不得不采用的方式,一般不要采用。如果下列情况出现时可以考虑采用这种方式关闭数据库。

1、 数据库处于一种非正常工作状态,不能用shutdown normal或者shutdown immediate这样的命令关闭数据库;

2、 需要立即关闭数据库;

3、 在启动数据库实例时遇到问题;

所有正在运行的SQL语句都将立即中止。所有未提交的事务将不回滚。Oracle也不等待目前连接到数据库的用户退出系统。下一次启动数据库时需要进行实例恢复,因此,下一次启动可能比平时需要更多的时间。

下表为上述四种不同关闭数据库的区别和联系。

关闭方式 Abort Immediate Transaction Nornal

允许新的连接 × × × ×

等待直到当前会话中止 × × × √

等待直到当前事务中止 × × √ √

强制CheckPoint,关闭所有文件 × √ √ √

以上就是关于如何恢复tempdb数据库全部的内容,包括:如何恢复tempdb数据库、电脑上数据库坏了该如何恢复正常、怎么用sql语句备份恢复sql2008数据库等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9765719.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-01
下一篇 2023-05-01

发表评论

登录后才能评论

评论列表(0条)

保存