Linux环境中使用Ext3文件系统

Linux环境中使用Ext3文件系统
Linux环境中使用Ext3文件系统

Linux环境中使用Ext3文件系统

Linux缺省情况下使用的文件系统为Ext2,ext2文件系统的确高效稳定。但是,随着Linux系统在关键业务中的应用,Linux文件系统的弱点也渐渐显露出来了;其中系统缺省使用的ext2文件系统是非日志文件系统。这在关键行业的应用是一个致命的弱点。本文向各位介绍Linux下使用ext3日志文件系统应用。

Ext3文件系统是直接从Ext2文件系统发展而来,目前ext3文件系统已经非常稳定可靠。它完全兼容ext2文件系统。用户可以平滑地过渡到一个日志功能健全的文件系统中来。这实际上了也是ext3日志文件系统初始设计的初衷。

一、Ext3日志文件系统的特点

1、高可用性

系统使用了ext3文件系统后,即使在非正常关机后,系统也不需要检查文件系统。宕机发生后,恢复ext3文件系统的时间只要数十秒钟。

2、数据的完整性:

ext3文件系统能够极大地提高文件系统的完整性,避免了意外宕机对文件系统的破坏。在保证数据完整性方面,ext3文件系统有2种模式可供选择。其中之一就是“同时保持文件系统及数据的一致性”模式。采用这种方式,你永远不再会看到由于非正常关机而存储在磁盘上的垃圾文件。

3、文件系统的速度:

尽管使用ext3文件系统时,有时在存储数据时可能要多次写数据,但是,从总体上看来,ext3比ext2的性能还要好一些。这是因为ext3的日志功能对磁盘的驱动器读写头进行了优化。所以,文件系统的读写性能较之Ext2文件系统并来说,性能并没有降低。

4、数据转换

由ext2文件系统转换成ext3文件系统非常容易,只要简单地键入两条命令即可完成整个转换过程,用户不用花时间备份、恢复、格式化分区等。用一个ext3文件系统提供的小工具tune2fs,它可以将ext2文件系统轻松转换为ext3日志文件系统。另外,ext3文件系统可以不经任何更改,而直接加载成为ext2文件系统。

5、多种日志模式

Ext3有多种日志模式,一种工作模式是对所有的文件数据及metadata(定义文件系统中数据的数据,即数据的数据)进行日志记录(data=journal模式);另一种工作模式则是只对metadata记录日志,而不对数据进行日志记录,也即所谓data=ordered或者

data=writeback模式。系统管理人员可以根据系统的实际工作要求,在系统的工作速度与文件数据的一致性之间作出选择。

二、使用Ext3文件系统

1.下载与编译核心

对核心打补丁,补丁下载地址:之后运行:

#make menuconfig

在Filesystem菜单中,会多出以下选项,选择内核支持Ext3文件系统:

<*> Ext3 journalling file system support (EXPERIMENTAL)

JBD (ext3) debugging support

选择支持Ext3文件系统,保存核心配置文件,重新编译核心。

#make bzImage

#make module

#make module_install

#make install

内核编译安装完成。使用新的内核启动系统后,就可以创建ext3文件系统了。

2.实际使用Ext3文件系统

创建新的ext3文件系统,例如要把磁盘上的hda5分区格式化ext3文件系统,并将日志记录在/dev/hda1分区,那么操作过程如下:

[root@test /sbin]# ./mke2fs -j /dev/sda5

mke2fs 1.24a (02-Sep-2001)

Filesystem label=

OS type: Linux

Block size=1024 (log=0)

.. .. ..

Creating journal (8192 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

在创建新的文件系统时,可以看到,ext3文件系统执行自动检测的时间为180天或每第31次被mount时,实际上这个参数可以根据需要随意调节。

以下将新的文件系统mount到主分区ext3目录下:

#[root@test /sbin]# mount -t ext3 /dev/sda5 /ext3

说明:以上将已格式化为ext3文件系统的/dev/sda5分区加载到/ext3目录下。

ext3 基于ext2 的代码,它的磁盘格式和ext2 的相同;这意味着,一个干净卸装的ext3 文件系统可以作为ext2 文件系统重新挂装。Ext3文件系统仍然能被加载成ext2文件系统来使用,你可以把一个文件系统在ext3和ext2自由切换。这时在ext2文件系统上的ext3日志文件仍然存在,只是ext2不能认出日志而已。

3.将ext2文件系统转换为ext3文件系统

将linux系统的文件系统由ext2转至ext3,有以下几处优点:第一系统的可用性增强了,第二数据集成度提高,第三启动速度提高了,第四ext2与ext3文件系统之间相互转换容易。

以转换文件系统为例,将ext2文件系统转换为ext3文件系统,命令如下:

[root@test /sbin]# ./tune2fs -j /dev/sda6

tune2fs 1.24a (02-Sep-2001)

Creating journal inode: done

This filesystem will be automatically checked every 31 mounts or

180 days, whichever comes first. Use tune2fs -c or -i to override.

这样,原来的ext2文件系统就转换成了ext3文件系统。注意将ext2文件系统转换为ext3文件系统时,不必要将分区缷载下来转换。

转换完成后,不要忘记将/etc/fstab文件中所对应分区的文件系统由原来的ext2更改为ext3。如果你正在转换的分区为根分区,你还应使用initrd启动系统,运行mkinitrd,确保lilo或grub能正常加载initrd。如果你没有做以上几步,那么根在下次启动时仍然会以ext2文件系统的方式加载。要查看根分区目前的文件系统,可以运行“cat /proc/mounts”查看结果,有关对根文件系统的转换,可以从随ext3软件包的说明手册中找到详细说明

4.日志的存放位置

可以将日志放置在另外一个存储设备上,例如存放到分区/dev/hda9。例如要在

/dev/hda5上创建一个ext3文件系统,并将日志存放在外部设备/dev/hda9上,则运行以下命令:

#mke2fs -J device=/dev/hda9 /dev/hda5

5.文件系统修复

新的e2fsprogs中的e2fsck支持ext3文件系统。当一个ext3文件系统被破坏时,先卸载该设备,在用e2fsck修复:

#umount /dev/hda6

#e2fsck -fy /dev/hda6

总之,ext3日志文件系统是目前linux系统由ext2文件系统过度到日志文件系统最为简单的一种选择,实现方式也最为简洁。由于是直接从ext2文件系统发展而来,系统由ext2文件系统过渡到ext3日志文件系统升级过程平滑,可以最大限度地保证系统数据的安全性。目前linux系统要使用日志文件系统,最保险的方式就是选择ext3文件系统。

3.ext2ext3 文件系统管理

CentOS 丛书目录 — 系统管理 — 网络服务 — 应用部署 ext2/ext3 文件系统管理 ext2/ext3 文件系统管理工具 在 e2fsprogs 软件包中提供了 ext2/ext3 文件系统管理工具。下面列出常用工具的说明: 创建 ext2/ext3 文件系统 mke2fs 命令用于创建 ext2/ext3 文件系统。mkfs.ext2 和 mkfs.ext3 命令都是 mke2fs 的硬链接,当使用 man mkfs.ext2 和 man mkfs.ext3 命令查看手册页时都定向到 mke2fs 。 mke2fs 命令的格式如下: 格式1: mke2fs [<选项>...] <设备名> [blocks-count] 格式2: mke2fs -j [<选项>...] <设备名> [blocks-count] 说明: 格式1用于创建 ext2 文件系统;格式2用于创建 ext3 日志文件系统。 blocks-count 用于指定要创建的文件系统的块数,此值应该小于 fdisk 命令查看的此分区或逻辑卷的块数,若省略此参数将使用整个分区或逻辑卷创建文件系统。 内容提要 1.熟悉 ext2/ext3 文件系统管理工具 2.学会使用 mke2fs 创建 ext2/ext3 文件系统 3.学会使用 e2fsck 检查 ext2/ext3 文件系统 4.学会使用 tune2fs 调整 ext2/ext3 文件系统的属性 工具 说明 /sbin/fsck 文件系统检查的前端工具 /sbin/e2fsck 检查和修复 ext2 或 ext3 文件系统 /sbin/fsck.ext2 检查和修复 ext2 文件系统 /sbin/fsck.ext3 检查和修复 ext3 文件系统 /sbin/mke2fs 创建 ext2 或 ext3 文件系统 /sbin/mkfs.ext2 创建 ext2 文件系统 /sbin/mkfs.ext3 创建 ext3 文件系统 /sbin/badblocks 检查磁盘分区坏块 /sbin/tune2fs 调整 ext2/ext3 文件系统的可调属性参数 /sbin/dumpe2fs 显示 ext2/ext3 文件系统的超级块和块组信息 /sbin/debugfs ext2/ext3 文件系统调试器 /sbin/e2label 显示或者修改 ext2/ext3 文件系统的卷标 /sbin/findfs 根据 ext2/ext3 文件系统的卷标或 UUID (全局唯一标识符,Universally Unique Identifier )查找对 应的设备 /sbin/resize2fs 更改 ext2/ext3 文件系统的容量

SQL Server 数据库清除日志的方法

SQL Server 数据库清除日志的方法 方法一: 1、打开查询分析器,输入命令 BACKUP LOG database_name WITH NO_LOG 2、再打开企业管理器--右键要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至xxm,这里会给出一个允许收缩到的最小m数,直接输入这个数,确定就可以了。 方法二: 设置检查点,自动截断日志 一般情况下,SQL数据库的收缩并不能很大程度上减小数据库大小,其主要作用是收缩日志大小,应当定期进行此操作以免数据库日志过大 1、设置数据库模式为简单模式:打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称(如用户数据库cwbase1)-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”,然后按确定保存 2、在当前数据库上点右键,看所有任务中的收缩数据库,一般里面的默认设置不用调整,直接点确定 3、收缩数据库完成后,建议将您的数据库属性重新设置为标准模式,操作方法同第一点,因为日志在一些异常情况下往往是恢复数据库的重要依据 方法三:通过SQL收缩日志 把代码复制到查询分析器里,然后修改其中的3个参数(数据库名,日志文件名,和目标日志文件的大小),运行即可 SET NOCOUNT ON DECLARE @LogicalFileNamesysname, @MaxMinutes INT, @NewSize INT USE tablename -- 要操作的数据库名 SELECT @LogicalFileName = 'tablename_log', -- 日志文件名 @MaxMinutes = 10, -- Limit on time allowed to wrap log. @NewSize = 1 -- 你想设定的日志文件的大小(M) -- Setup / initialize DECLARE @OriginalSizeint SELECT @OriginalSize = size FROM sysfiles WHERE name = @LogicalFileName SELECT 'Original Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName CREATE TABLE DummyTrans (DummyColumn char (8000) not null) DECLARE @Counter INT,

ext2和ext3的主要区别

在Red Hat Linux 7.2中,Red Hat首次支持日志文件系统ext3。ext3文件系统是对稳定的ext2文件系统的改进,有几项优点。本文概述这些优点,解释Red Hat公司对ext3进行了何种测试,略述性能调试(为高级用户)。 有数种基于Linux的日志文件系统正在开发之中。本文不言及这些日志文件系统,也不准备与这些日志文件系统进行比较。 ext3的优点 为什么你需要从ext2迁移到ext3呢?以下有四个主要原因:可用性、数据完整性、速度、易于迁移。 可用性 在非正常当机后(停电、系统崩溃),只有在通过e2fsck进行一致性校验后,ext2文件系统才能被装载使用。运行e2fsck的时间主要取决于ext2文件系统的大小。校验稍大一些的文件系统(几十GB)需要很长时间。如果文件系统上的文件数量多,校验的时间则更长。校验几百个GB的文件系统可能需要一个小时或更长。这极大地限制了可用性。 相比之下,除非发生硬件故障,即使非正常关机,ext3也不需要文件系统校验。这是因为数据是以文件系统始终保持一致方式写入磁盘的。在非正常关机后,恢复ext3文件系统的时间不依赖于文件系统的大小或文件数量,而依赖于维护一致性所需“日志”的大小。使用缺省日志设置,恢复时间仅需一秒(依赖于硬件速度)。 数据完整性 使用ext3文件系统,在非正常关机时,数据完整性能得到可靠的保障。你可以选择数据保护的类型和级别。你可以选择保证文件系统一致,但是允许文件系统上的数据在非正常关机时受损;这是可以在某些状况下提高一些速度(但非所有状况)。你也可以选择保持数据的可靠性与文件系统一致;这意味着在当机后,你不会在新近写入的文件中看到任何数据垃圾。这个保持数据的可靠性与文件系统一致的安全的选择是缺省设置。 速度 尽管ext3写入数据的次数多于ext2,但是ext3常常快于ext2(高数据流)。这是因为ext3的日志功能优化硬盘磁头的转动。你可以从3种日志模式中选择1种来优化速度,有选择地牺牲一些数据完整性。 第一种模式,data=writeback,有限地保证数据完整,允许旧数据在当机后存在于文件当中。这种模式可以在某些情况下提高速度。(在多数日志文件系统中,这种模式是缺省设置。这种模式为ext2文件系统提供有限的数据完整性,更多的是为了避免系统启动时的长时间的文件系统校验) 第二种模式,data=orderd(缺省模式),保持数据的可靠性与文件系统一致;这意味着在当机后,你不会在新近写入的文件中看到任何垃圾数据。 第三种模式,data=journal,需要大一些的日志以保证在多数情况下获得适中的速度。在当机后需要恢复的时间也长一些。但是在某些数据库操作时速度会快一些。 在通常情况下,建议使用缺省模式。如果需要改变模式,请在/etc/fstab文件中,为相应的文件系统加上data=模式的选项。详情可参看mount命令的man page在线手册(执行man mount)。 易于迁移 你可以不重新格式化硬盘,并且很方便的从ext2迁移至ext3而享受可靠的日志文件系统的好处。对,不需要做长时间的、枯燥的、有可能失误的“备份-重新格式化-恢复”操作,就可以体验ext3的优点。有两种迁移的方法: ·如果你升级你的系统,Red Hat Linux安装程序会协助迁移。需要你做的工作就是为每一

数据库的事务日志已满

数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ,请参阅sys.databases 中的log_reuse_wait_desc 列 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. 1、清空日志 DBCC SHRINKFILE(库名_log,0) DUMP TRANSACTION 库名WITH NO_LOG 2、截断事务日志: 如果出现“未能在sysfiles 中找到文件库名_log'。 DBCC 执行完毕。如果DBCC 输出了错误信息,请与系统管理员联系。” 则使用这句SQL操作 BACKUP LOG 库名WITH NO_LOG DBCC SHRINKFILE(2,0) 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 a、选择日志文件--收缩文件至,这里会给出一个允许收缩到的最小M数,确定就可以了 b、选择数据文件--收缩文件至,这里会给出一个允许收缩到的最小M数,,确定就可以了也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDA TABASE(库名) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)

a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG,大小只有500多K 或用代码: 下面的示例分离pubs,然后将pubs 中的一个文件附加到当前服务器。a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩,做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '库名','autoshrink','TRUE' 6.如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 库名modify file(name=逻辑文件名,maxsize=20)

MSSQL2000中没有日志文件的数据库恢复方法

MSSQL2000 中没有日志文件的数据库恢复方法 由于种种原因, 我们如果当时仅仅备份了 mdf 文件,那么恢复起来就是一件 很麻烦的事情了。 如果您的 mdf 文件是当前数据库产生的,那么很侥幸,也许你使用 sp_attach_db 或者 sp_attach_single_file_db 可以恢复数据库,但是会出现类 似下面的提示信息 ########################################################## 设备激活错误。 物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。 已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。 ########################################################## 但是,如果您的数据库文件是从其他计算机上复制过来的,那么很不幸,也 许上述办法就行不通了。你也许会得到类似下面的错误信息 ########################################################## 服务器: 消息 1813,级别 16,状态 2,行 1 未能打开新数据库 'test'。CREATE DATABASE 将终止。 设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。 ########################################################## 当出现以上问题时,恢复的办法如下: A.我们使用默认方式建立一个供恢复使用的数据库(数据库名应该与要恢复 的数据库相同,如 test)。可以在 SQL Server Enterprise Manager 里面建立。 B.停掉数据库服务器。 C.将刚才生成的数据库的日志文件 test_log.ldf 删除,用要恢复的数据库 mdf 文件覆盖刚才生成的数据库数据文件 test_data.mdf。 D.启动数据库服务器。此时会看到数据库 test 的状态为“置疑”。这时候 不能对此数据库进行任何操作。 E.设置数据库允许直接操作系统表。此操 作可以在 SQL Server Enterprise Manager 里面选择数据库服务器,按右键,选 择“属性”, 在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。 也可以使用如下语句来实现。

Ext3文件系统

EXT3文件系统 EXT2和EXT3是许多Linux操作系统发行版本的默认文件系统。EXT基于UFS,是一种快速、稳定的文件系统。 随着Linux系统在关键业务中的应用,Linux文件系统的弱点也渐渐显露出来了;其中EXT2文件系统是非日志式文件系统,这在关键行业的应用是一个致命的弱点,EXT3文件系统弥补了这一缺点。 EXT3文件系统是直接从EXT2文件系统发展而来,目前EXT3文件系统已经非常稳定可靠。它完全兼容EXT2文件系统。用户可以平滑地过渡到一个日志功能健全的文件系统中来。这实际上了也是EXT3日志文件系统初始设计的初衷。 Ext3文件系统属于一种日志文件系统,是对Ext2系统的扩展。Ext3系统兼容Ext2文件系统,二者之间的相互转换并不复杂。 Ext2是 GNU/Linux 系统中标准的文件系统,其簇快取层的优良设计使得Ext2系统存取文件的性能非常好,尤其是针对中小型的文件更显优势。 Ext3是一种日志式文件系统,日志文件系统比传统的文件系统安全,因为它用独立的日志文件跟踪磁盘内容的变化。就像关系型数据库(RDBMS),日志文件系统可以用事务处理的方式,提交或撤消文件系统的变化。由于文件系统都有快取层参与运作,不使用时必须将文件系统卸下,以便将快取层的资料写回磁盘中。因此每当系统要关机时,必须将其所有的文件系统全部关闭后才能进行关机。 如果在文件系统尚未关闭前就关机 (如停电) 时,下次重开机后会造成文件系统的资料不一致,故(所以)这时必须做文件系统的重整工作,将不一致与错误的地方修复。然而这一重整的工作是相当耗时的,特别是容量大的文件系统,而且也不能百分之百保证所有的资料都不会流失。 为了克服此问题,使用(便出现了)所谓的日志式文件系统 (Journal File System) 。此类文件系统最大的特色是,它会将整个磁盘的写入动作完整记录在磁盘的某个区域上,以便有需要时可以回溯追踪。 由于资料的写入动作包含许多的细节,如改变文件标头资料、搜寻磁盘可写入空间、一个个写入资料区段等等,每一个细节进行到一半若被中断,就会造成文件系统的不一致,因而需要重整。 然而在日志式文件系统中,由于详细纪录了每个细节,故当在某个过程中被中断时,系统可以根据这些记录直接回溯并重整被中断的部分,而不必花时间去检查其他的部分,故重整的工作速度相当快,几乎不需要花时间。 EXT3日志文件系统的特点 1、高可用性 系统使用了EXT3文件系统后,即使在非正常关机后,系统也不需要检查文件系统。宕机发生后,恢复EXT3文件系统的时间只要数十秒钟。 2、数据的完整性: EXT3文件系统能够极大地提高文件系统的完整性,避免了意外宕机对文件系统的破

数据库日志管理

一数据库日志文件管理 SQL SERVER日志清除的两种方法 在使用过程中大家经常碰到数据库日志非常大的情况,在这里介绍了两种处理方法...... 方法一: 一般情况下,SQL数据库的收缩并不能很大程度上减小数据库大小,其主要作用是收缩日志大小,应当定期进行此操作以免数据库日志过大。 1、设置数据库模式为简单模式:打开SQL企业管理器,在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选 择你的数据库名称-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择"简单",然后按确定保存。 2、在当前数据库上点右键,看所有任务中的收缩数据库,一般里面的默认设置不用调整,直接点确定。 3、收缩数据库完成后,建议将您的数据库属性重新设置为标准模式,操作方法同第一点,因为日志在一些异常情况下往往是恢复数据库的重要依据 方法二: 如果日志文件过于庞大,使用数据库收缩已经不能解决问题,可以考虑使用以下的方法。 对数据库进行分离,分离后将日志文件改名,然后重新附加数据库,此时会提示没有正确的日志文件,不要管,在附加过程中会重新生成日志文件。 完成后,在数据库属性中重新设置日志文件的大小,可设置为5G,这样就把原来的日志清除掉了。 注意:该方法在使用过程中,可能对数据库分离时间点上的数据有影响,因此,如果出现问题,请重新恢复该部分数据。或者在停止业务一段时间后再进行操作。 在SQL Server 2000企业管理器里面收缩数据库日志 操作环境:Windows 2000 Server 简体中文版+ sp4、SQL Server 2000标准版+sp4 任务描述: 在企业管理器里面收缩数据库日志 以下为操作截屏:

Linux ext3

Linux ext3 在Red Hat Linux 7.2版中,Red Hat首次支持了日志文件系统的ext3文件系统。该文件系统是在ext2文件系统的基础上进行了改进,是使用了日志功能的ext2文件系统加强版。ext3文件系统为ext2文件系统共享了所的磁盘设备,并添加了向ext2文件系统转换的能力。 ext3基于ext2的代码,所以它的磁盘格式和ext2的相同,这意味着一个干净卸载的ext3文件系统可以作将ext2文件系统毫无问题地重新挂装。ext3文件系统和ext2文件系统都使用相同的元数据,因而有可能执行ext2文件系统到ext3文件系统的现场升级,从ext2文件系统升级到ext3只需要短短的几分钟。 1.日志(Journaling) 日志块设备层(JBD,Journaling block device layer)完成ext3文件系统日志功能。JBD不是ext3文件系统所特有的,它的设计目标是为了向一个块设备添加日志功能。当一个修改执行时,ext3文件系统代码将通知JBD,称为一个事务(transaction)。如果在事务执行时突然断电或出现其他情况导致事务终止,日志功能具有的重放功能,能重新执行中断的事务。日志中有三种数据模式:第一种模式:data=writeback。在这种模式里ext3文件系统根本不处理任何形式的日志数据(如XFS、JFS和ReiserFS)。尽管事实上它提供有限的数据完整性并能摧毁用户最近修改的文件,但这种模式能给用户整体上的最高性能。 第二种模式:data=ordered,在这种模式下ext3文件系统只记录元数据日志,但它将元数据和数据分组成一个单元称为事务(transaction)。这种模式保持数据的可靠性与文件系统一致性,这意味着在系统崩溃后,用户不会在新近写入的文件中看到任何垃圾数据。总体来说这种模式的性能远远低于data=writeback模式,但却比data=journal模式快很多。 第三种模式:data=journal。这种模式提供了完整的数据及元数据日志,所有新数据,首先被写入日志,然后才被定位。当发生灾难性故障后,日志可以被重新播放,将数据和元数据带回到一致状态。这种模式的整体性能是最慢的,但数据需要从磁盘读取和写入磁盘时却是三种模式中最快的。 2.ext3文件系统的优点 ext3文件系统在ext2文件系统的基础了做出了很大改进,并解决了ext2文件系统的缺点。除了具有明显的优点外,ext3文件系统还具有以下特点: 可用性 ext3文件系统提供了登记报表方式,这意味着非正常系统关机后没必要再进行类似ext2中fsck的检查。ext3文件系统的检查只在一些罕见的硬件失效的情况下发生。非法系统关机后,ext3文件系统的恢复时间不根据文件系统的大小或文件的数量而定,而是根据用于维护一致性的登记日志文件的大小而定。

数据库系统形考选择题

数据库系统形考选择题 1.关于数据库管理系统的说法,错误的是( C )。 A.数据库管理系统与操作系统有关,操作系统的类型决定了能够运行的数据库管理系统的类型 B.数据库管理系统对数据库文件的访问必须经过操作系统才能实现 C.数据库应用程序可以不经过数据库管理系统而直接读取数据库文件 D.数据库管理系统对用户隐藏了数据库文件的存放位置和文件名 2.关于用文件管理数据的说法,错误的是( D )。 A.用文件管理数据,难以提供应用程序对数据的独立性 B.当存储数据的文件名发生变化时,必须修改访问数据文件的应用程序 C.用文件存储数据的方式难以实现数据访问的安全控制 D.将相关的数据存储在一个文件中,有利于用户对数据进行分类,因此也可以加快用户操作数据的效率 3.数据库系统的物理独立性是指( D )。 A.不会因为数据的变化而影响应用程序 B.不会因为数据存储结构的变化而影响应用程序 C.不会因为数据存储策略的变化而影响数据的存储结构 D.不会因为数据逻辑结构的变化而影响应用程序 4.数据库系统是由若干部分组成的。下列不属于数据库系统组成部分的是( B )。 A.数据库B.操作系统 C.应用程序D.数据库管理系统 5.数据库三级模式结构的划分,有利于(A )。 A. 数据的独立性 B. 管理数据库文件 C. 建立数据库 D. 操作系统管理数据库 6.在数据库的三级模式中,描述数据库中全体数据的逻辑结构和特征的是( B )。 A.内模式 B.模式 C. 外模式 D. 其他 7.在用数据模型描述数据时,一般要求数据模型要满足三个要求。下列描述中,不属于数据 模型应满足的要求的是( A )。 A.A.能够描述并发数据B.能够真实地模拟现实世界 B.C.容易被业务人员理解D.能够方便地在计算机上实现 8.数据模型三要素是指(B )。 A.数据结构、数据对象和数据共享 B.数据结构、数据操作和数据完整性约束 C.数据结构、数据操作和数据的安全控制 D.数据结构、数据操作和数据的可靠性 9.下列关于实体联系模型中联系的说法,错误的是( D )。 A.一个联系可以只与一个实体有关 B.一个联系可以与两个实体有关 C.一个联系可以与多个实体有关

liunx(btrfs,ext3,ext4,jfs,reiserfs,xfs)文件系统比较

文件系统btrfs ext3ext4jfs reiserfs reiser4xfs ntfs zfs 最大卷容量16 EB32 TB 1 EB (16TB)32 PB16 TB??16 EB256 TB16 EB 最大文件容量16 EB 2 TB16 TB 4 PB8TB8TB8 EB16 TB16 EB 目录结构 B tree list/tree list/Htree B tree B+ tree dancing B* tree B+ tree B+ tree hash table 文件分配extents bitmap/table bitmap/extents bitmap/extents bitmap??extents bitmap?? ACLS Yes Yes Yes Yes No No Yes ACLS only Yes checksum Yes No journal No No No No No Yes 透明压缩Yes No No No No Plugin No Yes Yes 透明加密No No No No No Plugin No Yes Yes online defrag Yes No Yes Yes No Yes Yes Yes Yes shrink Yes Yes Yes No Offline resize Offline No Yes No 全填充速率 全填充利用率0.89450.90650.90470.99590.99270.9918大文件效率14.67617.43510.725513.749314.31912.7093大文件删除 2.693 5.262 2.4220.037 1.8020.296小文件效率9.949 5.131 2.786640.94913.6058.978小文件删除 6.73710.7227 1.3916.116 2.756 5.653循环列文件0.1240.0890.0020.0940.190.099大文件read204620619314511946598200391215377521970242大文件write1279625565960926461962617446841812466大文件rndread201277119262871934420198527314901991976056大文件rndwrite138040411870101294689144601113082101384804小文件read237589329348153019732270843725593712236197小文件write926602526469681710844237395810939536小文件rndread332464735445662702282373755140455752666753小文件rndwrite91027715259701244240191075617903931311261以上数据,在公司的debian testing上测定。机器型号Dell Inspiron 560s,CPU Dual-Core E5700,4G内存,硬盘WDC WD3200AAKS-75L9A0。系统是debian testing,内核2.6.39-2-amd64。全填充是用time dd if=/dev/zero of=abc来测试填满?一个分区的速度和容量。大文件是四个ISO文件,共1.3G,从tmpfs上复制到目标设备上的时间平均值,三次平均。小文件是pypy/python2.7/linux kernel2.6.39所有源码,总计49242个文件,629M。从tmpfs上复制到目标设备的时间平均值,三次平均。循环列文件是通过time find .测试效率。下面测试单位为bytes/sec,是iozone测试结果。 首先是文件利用率,btrfs/ext3/ext4会消耗10%左右的空间作为系统消耗。如果你需要比较高的磁盘利用率,请不要考虑这三种系统。也许你会认为,放文件又不会放满,必须空出部分来才能减少文件碎片。实际上,被消耗掉的空间也并不是白白消耗,你的所有数据,都会增加10%的系统消耗空间。因此ntfs的防碎片阀值(为了防止碎片化,磁盘使用率不应当高于)大约是85%,而ext3就只有75%-80%。 其次是大文件效率,除了ext3不予考虑外,其余系统都过的去。btrfs/ext4在删除大文件的时候耗时略多,大概是和管理特性有关。 第三是小文件效率。如果你需要用小文件,千万不要考虑jfs,慢到我无法相信。ext4比btrfs和xfs快了四倍左右,非常适合操作大量小文件。例如源码编译,有blog说ext4比xfs快数倍。

Ext3文件系统、NTFS文件系统、FAT32文件系统

Ext3文件系统、NTFS文件系统、FAT32文件系统 2009-06-27 16:31 --------------------------------Ext3-------------------------------------- Ext3 Ext3(Third extended file system) Ext3是一种日志式文件系统,是对ext2系统的扩展,它兼容ext2。日志式文件系统的优越性在于:由于文件系统都有快取层参与运作,如不使用时必须将文件系统卸下,以便将快取层的资料写回磁盘中。因此每当系统要关机时,必须将其所有的文件系统全部shutdown后才能进行关机。 如果在文件系统尚未shutdown前就关机 (如停电) 时,下次重开机后会造成文件系统的资料不一致,故这时必须做文件系统的重整工作,将不一致与错误的地方修复。然而,此一重整的工作是相当耗时的,特别是容量大的文件系统,而且也不能百分之百保证所有的资料都不会流失。 为了克服此问题,使用所谓‘日志式文件系统(Journal File System) ’。此类文件系统最大的特色是,它会将整个磁盘的写入动作完整记录在磁盘的某个区域上,以便有需要时可以回溯追踪。 由于资料的写入动作包含许多的细节,像是改变文件标头资料、搜寻磁盘可写入空间、一个个写入资料区段等等,每一个细节进行到一半若被中断,就会造成文件系统的不一致,因而需要重整。 然而,在日志式文件系统中,由于详细纪录了每个细节,故当在某个过程中被中断时,系统可以根据这些记录直接回溯并重整被中断的部分,而不必花时间去检查其他的部分,故重整的工作速度相当快,几乎不需要花时间。 Ext3概述 开发商:开放源代码 全称:Third extended file system 发布时间:2001年11月 (Linux 2.4.15) 分区标识:0x83 (MBR);EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) Ext3结构 目录内容:表, 树 文件分配:位图(空闲区域), 表(元数据) 坏块:表 限制 最大文件大小:16GiB – 64TiB 最大文件数量:可变 最长文件名限制:255字节 最大卷大小:2TiB – 32TiB 文件名允许的字符数:除NUL和'/'外的所有字节

K3数据库日志文件过大分析及解决方案V2.0要点

K/3数据库日志文件过大分析及解决方案 本期概述 ●本文档适用于金蝶k/3(使用SQL Server 2000、SQL Server 2005作为数据库)。 ●本文档主要阐述了,在K3备份过程中,遇到:”日志文件过 大,系统无法完成备份”的问题分析及解决方案。通过对本文档的学习,能够掌握这种问题产生的原因以及解决方法。 版本信息 ●2009年6月10日V11.0 编写人:周素帆 ●2009年6月日V11.0 修改人:

版权信息 本文件使用须知 著作权人保留本文件的内容的解释权,并且仅将本文件内容提供给阁下个人使用。对于内容中所含的版权和其他所有权声明,您应予以尊重并在其副本中予以保留。您不得以任何方式修改、复制、公开展示、公布或分发这些内容或者以其他方式把它们用于任何公开或商业目的。任何未经授权的使用都可能构成对版权、商标和其他法律权利的侵犯。如果您不接受或违反上述约定,您使用本文件的授权将自动终止,同时您应立即销毁任何已下载或打印好的本文件内容。 著作权人对本文件内容可用性不附加任何形式的保证,也不保证本文件内容的绝对准确性和绝对完整性。本文件中介绍的产品、技术、方案和配置等仅供您参考,且它们可能会随时变更,恕不另行通知。本文件中的内容也可能已经过期,著作权人不承诺更新它们。如需得到最新的技术信息和服务,您可向当地的金蝶业务联系人和合作伙伴进行咨询。 著作权声明著作权所有2009 金蝶软件(中国)有限公司。

所有权利均予保留。

目录 第一章报错现象及分析 (5) 一、报错现象 (5) 二、问题分析 (6) 三、关于日志文件 (6) 第二章解决方案 (8) 一、SQL 2000 (8) 1、执行数据库分离附加 (8) 2、数据库收缩操作 (18) 二、SQL 2005 (24) 1、分离附加数据库 (24) 2、收缩数据库 (27)

EXT2、EXT3、EXT4、XFS、GPT详解

EXT2、EXT3、EXT4、XFS、GPT详解 原创:运维老司机小柒博客 7月18日 EXT2与EXT3区别 Linux之前缺省情况下使用的文件系统为Ext2,ext2文件系统的确高效稳定。但是,随着Linux系统在关键业务中的应用,Linux文件系统的弱点也渐渐显露出来了:其中系统缺省使用的ext2文件系统是非日志文件系统。这在关键行业的应用是一个致命的弱点,Ext3文件系统是直接从Ext2文件系统发展而来,目前ext3文件系统已经非常稳定可靠。它完全兼容ext2文件系统。用户可以平滑地过渡到一个日志功能健全的文件系统中来。这实际上了也是ext3日志文件系统初始设计的初衷。 1) ext3和ext2的主要区别在于,ext3引入Journal(日志)机制,Linux 内核从2.4.15开始支持ext3,它是从文件系统过渡到日志式文件系统最为简单的一种选择,ext3提供了数据完整性和可用性保证。 2) ext2和ext3的格式完全相同,只是在ext3硬盘最后面有一部分空间用来 存放Journal的记录; 3) 在ext2中,写文件到硬盘中时,先将文件写入缓存中,当缓存写满时才 会写入硬盘中;

4) 在ext3中,写文件到硬盘中时,先将文件写入缓存中,待缓存写满时系 统先通知Journal,再将文件写入硬盘,完成后再通知Journal,资料已完成写入工作; 5) 在ext3中,也就是有Journal机制里,系统开机时检查Journal的内容, 来查看是否有错误产生,这样就加快了开机速度; EXT3日志文件系统的特点 1、高可用性 系统使用了ext3文件系统后,即使在非正常关机后,系统也不需要检查文件系统。宕机发生后,恢复ext3文件系统的时间只要数十秒钟。 2、数据的完整性 ext3文件系统能够极大地提高文件系统的完整性,避免了意外宕机对文件系统的破坏。在保证数据完整性方面,ext3文件系统有2种模式可供选择。 其中之一就是"同时保持文件系统及数据的一致性"模式。采用这种方式,你永远不再会看到由于非正常关机而存储在磁盘上的垃圾文件。 3、文件系统的速度 尽管使用ext3文件系统时,有时在存储数据时可能要多次写数据,但是,从总体上看来,ext3比ext2的性能还要好一些。这是因为ext3的日志功能对磁盘的驱动器读写头进行了优化。所以,文件系统的读写性能较之Ext2文件系统并来说,性能并没有降低。

数据库在使用过程中会使日志文件不断增加

数据库在使用过程中会使日志文件不断增加,使得数据库的性能下降,并且占用大量的磁盘空间。SQL Server数据库都有log文件,log文件记录用户对数据库修改的操作。可以通过直接删除log文件和清空日志在清除数据库日志。 一、删除LOG 1、分离数据库。分离数据库之前一定要做好数据库的全备份,选择数据库——右键——任务——分离。 勾选删除连接

分离后在数据库列表将看不到已分离的数据库。 2、删除LOG文件 3、附加数据库,附加的时候会提醒找不到log文件。

删除数据库信息信息的ldf文件: 附加数据库之后将生成新的日志文件log,新的日志文件的大小事504K。 也可以通过命令才完成以上的操作: use master; exec sp_detach_db @dbname='TestDB'; exec sp_attach_single_file_db @dbname='TestDB',@physname='D:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\TestDB.mdf' 二、清空日志 该命令在SQL Server 2005和2000支持,SQL Server 2008不支持该命令。

DUMP TRANSACTION TestDB WITH NO_LOG 三、收缩数据库文件 DBCC SHRINKFILE ('TestDB_log',1) 四、截断事务日志 BACKUP LOG TestDB WITH NO_LOG 该命令在SQL Server 2008也是不支持,在SQL Server 2005和2000可以使用。 清除SQLServer2005的LOG文件 --最好备份日志,以后可通过日志恢复数据。。。 以下为日志处理方法 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. --*/ --下面的所有库名都指你要处理的数据库的库名 1.清空日志 DUMP TRANSACTION库名WITH NO_LOG 2.截断事务日志: BACKUP LOG库名WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 也可以用SQL语句来完成 --收缩数据库

3种分布式文件系统

第一部分CEPH 1.1 特点 Ceph最大的特点是分布式的元数据服务器通过CRUSH,一种拟算法来分配文件的locaiton,其核心是 RADOS(resilient automatic distributed object storage),一个对象集群存储,本身提供对象的高可用,错误检测和修复功能。 1.2 组成 CEPH文件系统有三个主要模块: a)Client:每个Client实例向主机或进程提供一组类似于POSIX的接口。 b)OSD簇:用于存储所有的数据和元数据。 c)元数据服务簇:协调安全性、一致性与耦合性时,管理命名空间(文件名和 目录名) 1.3 架构原理 Client:用户 I/O:输入/输出 MDS:Metadata Cluster Server 元数据簇服务器 OSD:Object Storage Device 对象存储设备

Client通过与OSD的直接通讯实现I/O操作。这一过程有两种操作方式: 1. 直接通过Client实例连接到Client; 2. 通过一个文件系统连接到Client。 当一个进行打开一个文件时,Client向MDS簇发送一个请求。MDS通过文件系统层级结构把文件名翻译成文件节点(inode),并获得节点号、模式(mode)、大小与其他文件元数据。注意文件节点号与文件意义对应。如果文件存在并可以获得操作权,则MDS通过结构体返回节点号、文件长度与其他文件信息。MDS同时赋予Client操作权(如果该Client还没有的话)。目前操作权有四种,分别通过一个bit表示:读(read)、缓冲读(cache read)、写(write)、缓冲写(buffer write)。在未来,操作权会增加安全关键字,用于client向OSD证明它们可以对数据进行读写(目前的策略是全部client 都允许)。之后,包含在文件I/O中的MDS被用于限制管理能力,以保证文件的一致性与语义的合理性。 CEPH产生一组条目来进行文件数据到一系列对象的映射。为了避免任何为文件分配元数据的需要。对象名简单的把文件节点需要与条目号对应起来。对象复制品通过CRUSH(著名的映射函数)分配给OSD。例如,如果一个或多个Client打开同一个文件进行读操作,一个MDS会赋予他们读与缓存文件内容的能力。通过文件节点号、层级与文件大小,Client可以命名或分配所有包含该文件数据的对象,并直接从OSD簇中读取。任何不存在的对象或字节序列被定义为文件洞或0。同样的,如果Client打开文件进行写操作。它获得使用缓冲写的能力。任何位置上的数据都被写到合适的OSD上的合适的对象中。Client 关闭文件时,会自动放弃这种能力,并向MDS提供新的文件大小(写入时的最大偏移)。它重新定义了那些存在的并包含文件数据的对象的集合。 CEPH的设计思想有一些创新点主要有以下两个方面: 第一,数据的定位是通过CRUSH算法来实现的。

LINUX EXT文件系统

EXT文件系统研究报告 EXT2 文件系统 The Second Extended File System(ext2)文件系统是Linux系统中的标准文件系统,是通过对Minix的文件系统进行扩展而得到的,其存取文件的性能极好。 在ext2文件系统中,文件由inode(包含有文件的所有信息)进行唯一标识。一个文件可能对应多个文件名,只有在所有文件名都被删除后,该文件才会被删除。此外,同一文件在磁盘中存放和被打开时所对应的inode是不同的,并由内核负责同步。 ext2文件系统采用三级间接块来存储数据块指针,并以块(block,默认为1KB)为单位分配空间。其磁盘分配策略是尽可能将逻辑相邻的文件分配到磁盘上物理相邻的块中,并尽可能将碎片分配给尽量少的文件,以从全局上提高性能。ext2文件系统将同一目录下的文件(包括目录)尽可能的放在同一个块组中,但目录则分布在各个块组中以实现负载均衡。在扩展文件时,会尽量一次性扩展8个连续块给文件(以预留空间的形式实现)。 一、文件系统特性 磁盘分区完毕后还需要进行格式化,之后操作系统才能够使用这个分区。这是因为每种操作系统所设置的文件属性/权限并不相同,为了存放这些文件所需的数据,因此就需要将分区进行格式化,以成为操作系统能够利用的文件系统格式。传统的磁盘与文件系统的应用中,一个分区誻只能够被格式化成为一个文件系统,所以我们可以说一个文件系统就是一个分区。 操作系统的文件数据除文件内容外,通常还有非常多的属性,Linux中的文件权限(rxw)与文件属性(所有者,群组、时间参数等)。文件系统通常会将这两部分数据分别存放在不同的块: 权限与属性放置到inode中. 至于实际数据则放置到data block块中。 另外还有一个超级块(super block)会记录整个文件系统的的整体信息,包括inode 与block的总量、使用量、剩余量,以及文件系统的格式与相关信息等。 inode:记录文件的属性,一个文件占用一个inode,同时记录此文件的数据所在的block 号码。 block:实际记录文件的内容,若文件太大时,会占用多个block。 由于每个inode与block都有编号,而每个文件都会占用一个inode,inode内则有文件数据放置的block号码。因此,如果能找到文件的inode的话,那么自然就会知道这个文件所放置数据的block号码,也就能够读出该文件的实际数据。

相关文档
最新文档