数据库碎片

❶ Access中,频繁删除数据库对象,数据库文件中的碎片不断增加,数据库文件也会越来越大,怎样解决最有效

两个办法
一，在
工具-选项-常规
，有个关闭时
压缩数据库
，打上勾，可以在关闭时清掉这些碎片。
二，在
工具-数据库实用工具-修复和压缩数据库，这个可以清掉这些碎片。

❷ 逐步讲解 Oracle数据库碎片如何整理

对于系统管理员来讲，如何保证网络稳定运行，如何提高数据库性能，使其更加安全高效，就显得尤为重要。作为影响数据库性能的一大因素 -- 数据库碎片，应当引起 DBA 的足够重视，及时发现并整理碎片乃是 DBA 一项基本维护内容。 1、碎片是如何产生的 当生成一个数据库时，它会分成称为表空间（ Tablespace ）的多个逻辑段（ Segment ），如系统（System）表空间 , 临时（Temporary）表空间等。一个表空间可以包含多个数据范围（Extent）和一个或多个自由范围块，即自由空间（Free Space）。 表空间、段、范围、自由空间的逻辑关系如下： 当表空间中生成一个段时，将从表空间有效自由空间中为这个段的初始范围分配空间。在这些初始范围充满数据时，段会请求增加另一个范围。这样的扩展过程会一直继续下去，直到达到最大的范围值，或者在表空间中已经没有自由空间用于下一个范围。最理想的状态就是一个段的数据可被存在单一的一个范围中。这样，所有的数据存储时靠近段内其它数据，并且寻找数据可少用一些指针。但是一个段包含多个范围的情况是大量存在的，没有任何措施可以保证这些范围是相邻存储的，当要满足一个空间要求时，数据库不再合并相邻的自由范围（除非别无选择）， 而是寻找表空间中最大的自由范围来使用。这样将逐渐形成越来越多的离散的、分隔的、较小的自由空间，即碎片。例如： 2、碎片对系统的影响 随着时间推移，基于数据库的应用系统的广泛使用，产生的碎片会越来越多，将对数据库有以下两点主要影响： 1）导致系统性能减弱。 如上所述，当要满足一个空间要求时，数据库将首先查找当前最大的自由范围，而 “最大”自由范围逐渐变小，要找到一个足够大的自由范围已变得越来越困难，从而导致表空间中的速度障碍，使数据库的空间分配愈发远离理想状态； 2）浪费大量的表空间。 尽管有一部分自由范围（如表空间的 pctincrease 为非 0 ）将会被 SMON （系统监控）后台进程周期性地合并，但始终有一部分自由范围无法得以自动合并，浪费了大量的表空间。 3、自由范围的碎片计算 由于自由空间碎片是由几部分组成，如范围数量、最大范围尺寸等，我们可用 FSFI--Free Space Fragmentation Index （自由空间碎片索引）值来直观体现： FSFI=100*SQRT(max(extent)/sum(extents))*1/SQRT(SQRT(count(extents))) 可以看出， FSFI 的最大可能值为 100 （一个理想的单文件表空间）。随着范围的增加， FSFI 值缓慢下降，而随着最大范围尺寸的减少， FSFI 值会迅速下降。 下面的脚本可以用来计算 FSFI 值： rem FSFI Value Compute rem fsfi.sql column FSFI format 999,99 select tablespace_name,sqrt(max(blocks)/sum(blocks))* (100/sqrt(sqrt(count(blocks)))) FSFI from dba_free_space group by tablespace_name order by 1; spool fsfi.rep; / spool off;比如，在某数据库运行脚本 fsfi.sql, 得到以下 FSFI 值： TABLESPACE_NAME FSFI ------------------------------------- RBS 74.06 SYSTEM 100.00 TEMP 22.82 TOOLS 75.79 USERS 100.00 USER_TOOLS 100.00 YDCX_DATA 47.34 YDCX_IDX 57.19 YDJF_DATA 33.80 YDJF_IDX 75.55统计出了数据库的 FSFI 值，就可以把它作为一个可比参数。在一个有着足够有效自由空间，且FSFI 值超过 30 的表空间中，很少会遇见有效自由空间的问题。当一个空间将要接近可比参数时，就需要做碎片整理了。 4、自由范围的碎片整理1）表空间的 pctincrease 值为非 0。 可以将表空间的缺省存储参数 pctincrease 改为非 0 。一般将其设为 1 ，如： alter tablespace temp default storage(pctincrease 1);这样SMON 便会将自由范围自动合并。也可以手工合并自由范围： alter tablespace temp coalesce。 5、段的碎片整理我们知道，段由范围组成。在有些情况下，有必要对段的碎片进行整理。要查看段的有关信息，可查看数据字典 dba_segments ，范围的信息可查看数据字典 dba_extents 。如果段的碎片过多， 将其数据压缩到一个范围的最简单方法便是用正确的存储参数将这个段重建，然后将旧表中的数据插入到新表，同时删除旧表。这个过程可以用 Import/Export （输入 / 输出）工具来完成。 Export （）命令有一个（压缩）标志，这个标志在读表时会引发 Export 确定该表所分配的物理空间量，它会向输出转储文件写入一个新的初始化存储参数 -- 等于全部所分配空间。若这个表关闭， 则使用 Import （）工具重新生成。这样，它的数据会放入一个新的、较大的初始段中。例如： exp user/password file=exp.dmp compress=Y grants=Y indexes=Y tables=(table1,table2);若输出成功，则从库中删除已输出的表，然后从输出转储文件中输入表： imp user/password file=exp.dmp commit=Y buffer=64000 full=Y 这种方法可用于整个数据库。 以上简单分析了 Oracle 数据库碎片的产生、计算方法及整理，仅供参考。数据库的性能优化是一项技术含量高，同时又需要有足够耐心、认真细致的工作。 对数据库碎片的一点探讨， 下面是一种如何自动处理表空间碎片的代码，希望对上大家看上文有用 Coalesce Tablespace Automatically This technique comes from Sandeep Naik, a database administrator for GSXXI, Inc. in New York City, New York Here is a handy script which can be scheled to automatically run and coalesces the tablespaces. This script is designed to run in NT but can be run in any operating system by slight modifications in the path where the file spools from the SQLPLUS environment. It assumes that the user who runs the script has priviledges to view the data dictionary. Start of code -------------------------------------- sqlplus / prompt this script will coalesce the tablespace automatically set verify off; set termout off; set head off; spool c: empcoalesce.log select alter tablespace ||TABLESPACE_NAME|| coalesce ; from DBA_FREE_SPACE_COALESCED where PERCENT_EXTENTS_COALESCED

❸ 什么是内部碎片什么是外部碎片各种存储管理中都可能产生何种碎片

1.内部碎片：

当一个进程装入到固定大小的分区块（比如页）时，假如进程所需空间小于分区块，则分区块的剩余的空间将无法被系统使用，称为内部碎片。

2.外部碎片：

指的是还没有被分配出去（不属于任何进程），但由于太小了无法分配给申请内存空间的新进程的内存空闲区域。

3.存储管理中都可能产生的碎片：

除了内部碎片和外部碎片，在“分页存储”中，可能产生“页内碎片”，页内碎片是由于进程的最后一页经常装不满一块而形成了不可利用的碎片。

(3)数据库碎片扩展阅读

在数据存储领域中，碎片(fragmentation）是指存储空间使用效率低下，结果导致功能、运行效率变低或二者兼而有之的现象。碎片化所造成的影响取决于具体的存储系统以及碎片化的种类。

大部分情况下，碎片化都会导致都会导致存储空间的浪费，此时“碎片”一词亦可指代闲置的空间本身。对于其他的一些系统来说（比如FAT文件系统），数据量一定的前提下，用于存储数据所占的存储空间是一定的，和碎片化的程度无关。

❹ 什么 是 数据库碎片

这里面有相关的解释希望能对你有所帮助
http://wenku..com/view/fe1f070203d8ce2f00662393.html

❺ arcgis中数据库碎片化整理会少数据么

不会的。因为这只会重新调整地理数据库在磁盘中的存储方式。

【拓展】数据库碎片整理：对个人地理数据库或文件地理数据库进行碎片整理。数据库碎片整理操作会重新调整地理数据库在磁盘中的存储方式，因而通常会减小地理数据库的大小并提高性能。

用法：

• 当个人地理数据库大于 250 MB 时，建议对数据库进行碎片整理。

• 如果频繁对某个数据库执行数据输入、删除或常规编辑，则应对该数据库进行定期碎片整理以确保最佳性能。

• 如果在 ArcMap 中打开了某个数据库以供编辑，则无法对其进行碎片整理。要对数据库进行碎片整理，可从“内容列表”中移除引用了该数据库中包含的表或要素类的所有图层。

开始行动：个人和文件地理数据库以二进制文件形式存储在磁盘驱动器中。添加、移除或编辑数据时，这些文件会产生碎片，降低数据库的整体性能。数据库碎片整理工具通过对这些二进制文件进行碎片整理，可重新整理数据库在磁盘中的存储方式，从而减少磁盘中数据库的大小并改善数据库性能。

❻ php怎么显示mysql数据库的碎片

MySQL 8.0.16 已经发布，它像往常一样增强了组复制 Group Replication 功能。

这篇文章介绍了 MySQL 8.0.16 为 Group Replication 带来的新功能：

Message fragmentation（信息碎片化）。

背景

Group Replication 目前使用 XCom（一种组通信引擎），特点：原子性，组员状态检测等。每个成员的组复制插件先将信息转发到本地 XCom，再由 XCom 最终以相同的顺序将信息传递给每个组成员的 Group Replication 插件。

XCom 由单线程实现。当一些成员广播信息过大时，XCom 线程必须花费更多的时间来处理那个大信息。如果成员的 XCom 线程忙于处理大信息的时间过长，它可能会去查看其他成员的 XCom 实例。例如，忙碌的成员失效。如果是这样，该组可以从该组中驱逐忙碌的成员。

MySQL 8.0.13 新增group_replication_member_expel_timeout系统变量，您可以通过它来调整将成员从组中驱逐的时间。例如，怀疑成员失败，但成员实际上忙于处理大信息，给成员足够的时间来完成处理。在这种情况下，是否为成员增加驱逐超时的设置是一种权衡。有可能等了很久，该成员实际真的失效了。

Message fragmentation（信息碎片化）

MySQL 8.0.16 的 Group Replication 插件新增用来处理大信息的功能：信息碎片化。

简而言之，您可以为成员的广播信息指定最大值。超过最大值的信息将分段为较小的块传播。

您可以使用 group_replication_communication_max_message_size系统变量指定允许的信息最大值（默认值为10 MiB）。

示例

让我们用一个例子来解释新功能。图1显示了当绿色成员向组广播信息时，新功能是如何处理的。

图1 对传出信息进行分段

1. 如果信息大小超过用户允许的最大值（group_replication_communication_max_message_size），则该成员会将信息分段为不超过最大值的块。

2. 该成员将每个块广播到该组，即将每个块单独转发到XCom。

XCom 最终将这些块提供给组成员。下面三张图展示出了中间绿色成员发送大信息时工作的新特征。

图2a 重新组合传入的信息：第一个片段

3. 成员得出结论，传入的信息实际上是一个更大信息的片段。

4. 成员缓冲传入的片段，因为他们认为片段是仍然不完整的信息的一部分。（片段包含必要的元数据以达到这个结论。）

图2b 重新组合传入的信息：第二个片段

5. 见上面的第3步。

6. 见上面的第4步。

图2c 重新组合传入的信息：最后一个片段

7. 成员得出结论，传入的信息实际上是一个更大信息的片段。

8. 成员得出结论，传入的片段是最后一个缺失的块，重新组合原始信息，然后对其进行处理，传输完毕。

结论

MySQL 8.0.16 已经发布后，组复制现在可以确保组内交换的信息大小不超过用户定义的阈值。这可以防止组内误判而驱逐成员。

❼ 清理数据库碎片SQL语句

清除数据库日志语句
--清除sqlserver 2000/2005 数据库日志
替换下红字部分数据库名称

declare @databasename varchar(15)
select @databasename='hdjjgl_journal'
DUMP TRANSACTION @databasename WITH NO_LOG

BACKUP LOG @databasename WITH NO_LOG

DBCC SHRINKDATABASE(@databasename)

或者
USE 数据库名
DUMP TRANSACTION 数据库名 WITH NO_LOG
BACKUP LOG 数据库名 WITH NO_LOG
DBCC SHRINKFILE(2)

**********************************
--清除sqlserver 2008 数据库日志 ,执行两遍
替换下红字部分数据库名称，建立datalogbak清楚的日志备份文件夹，注意路径自定义。

use gdzjg_journal
declare @databasename varchar(100)
declare @databasenamelog varchar(100)
declare @databasenamedir varchar(100)
select @databasename='gdzjg_journal'
select @databasenamelog=@databasename+'_log'
select @databasenamedir='g:\datalogbak\'+@databasename

BACKUP LOG @databasename to disk=@databasenamedir
DBCC SHRINKFILE (@databasenamelog,1)

或者

ALTER DATABASE 数据库名称SET RECOVERY SIMPLE
ALTER DATABASE 数据库名称SET RECOVERY FULL
DBCC SHRINKDATABASE(数据库名称,0)

sqlserver 2000、2008会保存所有的数据库操作过程，将指令保存在ldf文件中，如果误删除数据，想恢复数据的话，可以通过Lumigent Log Explorer For SQLServer 软件分析ldf文件，可以看到所有执行过的insert、update、delete数据，导出来再逆向执行即可，本人曾经用过一回，确实奏效。

1、sql server 2000清理数据库日志

USE 数据库名

DUMP TRANSACTION 数据库名 WITH NO_LOG
BACKUP LOG 数据库名 WITH NO_LOG
DBCC SHRINKFILE(2)

SHRINKFILE(2)，后面的2是file_id，可以在当前数据库用select * from sysfiles看得到，看数据库的log文件的fileid是多少，正常情况下log的ldf文件是2，mdf文件的fileid是1。
这个查询语句可以随时执行，不影响数据库的运行。

sql server 2005、2008清理数据库日志

USE 数据库名
ALTER DATABASE 数据库名 SET RECOVERY SIMPLE
ALTER DATABASE 数据库名 SET RECOVERY FULL
DBCC SHRINKDATABASE(数据库名,0)

这个查询语句可以随时执行，不影响数据库的运行。

清理ldf的操作可以使用sql server代理，每天自动执行一次，就不怕文件增长撑爆硬盘了。

2、一般mdf用不着收缩，收缩多了容易产生文件碎片，因为delete数据之后，mdf文件中可用页面空间会保留在那里，等下次有新数据进来时，会继续使用。如果实在要清理，可以参考下面的语句：

sql server 2000、2005、2008 收缩mdf文件

DBCC SHRINKDATABASE(数据库名)
DBCC SHRINKFILE(1,0)
DBCC UPDATEUSAGE(0)

执行上述操作后，你会发现mdf的文件减少了，ldf的文件增大了，再用上面1的日志清理操作一次即可。

3、最后再附送一个查看数据表的行数、占用文件空间、存储情况的查询语句

-- drop table #test
create table #test(
name varchar(50),
rows int,
reserved varchar(20),
data varchar(20),
index_size varchar(20),
unused varchar(20)
)
set nocount on
insert into #test
EXEC sp_MSforeachtable @command1="sp_spaceused '?'"
select * from #test order by cast(replace(reserved,'KB','') as int) desc

❽ 数据库碎片整理不影响业务使用

您好，您是想问数据库碎片整理不影响业务使用吗？数据库碎片整理不影响业务使用的，因为数据库在碎片整理时，为了防止影响使用是系统在后台进行运行整理的。数据库碎片整理时将数据库中不用的琐碎信息进行整理和分类。

❾ mysql 如何去整理表数据，碎片整理

MySQL 的碎片是 MySQL 运维过程中比较常见的问题，碎片的存在十分影响数据库的性能，本文将对 MySQL 碎片进行一次讲解。

判断方法：

MySQL 的碎片是否产生，通过查看

show table status from table_nameG;

这个命令中 Data_free 字段，如果该字段不为 0，则产生了数据碎片。

产生的原因：

1. 经常进行 delete 操作

经常进行 delete 操作，产生空白空间，如果进行新的插入操作，MySQL将尝试利用这些留空的区域，但仍然无法将其彻底占用，久而久之就产生了碎片；

演示：

创建一张表，往里面插入数据，进行一个带有 where 条件或者 limit 的 delete 操作，删除前后对比一下 Data_free 的变化。

删除前：

Data_free 不为 0，说明有碎片；

2. update 更新

update 更新可变长度的字段(例如 varchar 类型)，将长的字符串更新成短的。之前存储的内容长，后来存储是短的，即使后来插入新数据，那么有一些空白区域还是没能有效利用的。

演示：

创建一张表，往里面插入一条数据，进行一个 update 操作，前后对比一下 Data_free 的变化。

CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

更新语句：update t1 set k='aaa';

更新前长度：223 Data_free：0

更新后长度：3 Data_free：204

Data_free 不为 0，说明有碎片；

产生影响：

1. 由于碎片空间是不连续的，导致这些空间不能充分被利用；

2. 由于碎片的存在，导致数据库的磁盘 I/O 操作变成离散随机读写，加重了磁盘 I/O 的负担。

清理办法：

• MyISAM：optimize table 表名；（OPTIMIZE 可以整理数据文件,并重排索引）

• Innodb：

1. ALTER TABLE tablename ENGINE=InnoDB；(重建表存储引擎，重新组织数据)

2. 进行一次数据的导入导出

碎片清理的性能对比：

引用我之前一个生产库的数据，对比一下清理前后的差异。

SQL执行速度：

• select count(*) from test.twitter_11;




修改前：1 row in set (7.37 sec)

修改后：1 row in set (1.28 sec)

结论：

通过对比，可以看到碎片清理前后，节省了很多空间，SQL执行效率更快。所以，在日常运维工作中，应对碎片进行定期清理，保证数据库有稳定的性能。

❿ 数据库存储空间中碎片产生的原因　及如何回收碎片

以MySQL为例，碎片的存在十分影响性能

MySQL 的碎片是 MySQL 运维过程中比较常见的问题，碎片的存在十分影响数据库的性能，本文将对 MySQL 碎片进行一次讲解。

判断方法：

MySQL 的碎片是否产生，通过查看

show table status from table_nameG;

这个命令中 Data_free 字段，如果该字段不为 0，则产生了数据碎片。

产生的原因：

1. 经常进行 delete 操作

经常进行 delete 操作，产生空白空间，如果进行新的插入操作，MySQL将尝试利用这些留空的区域，但仍然无法将其彻底占用，久而久之就产生了碎片；

演示：

创建一张表，往里面插入数据，进行一个带有 where 条件或者 limit 的 delete 操作，删除前后对比一下 Data_free 的变化。

删除前：

Data_free 不为 0，说明有碎片；

2. update 更新

update 更新可变长度的字段(例如 varchar 类型)，将长的字符串更新成短的。之前存储的内容长，后来存储是短的，即使后来插入新数据，那么有一些空白区域还是没能有效利用的。

演示：

创建一张表，往里面插入一条数据，进行一个 update 操作，前后对比一下 Data_free 的变化。

CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

更新语句：update t1 set k='aaa';

更新前长度：223 Data_free：0

更新后长度：3 Data_free：204

Data_free 不为 0，说明有碎片；

产生影响：

1. 由于碎片空间是不连续的，导致这些空间不能充分被利用；

2. 由于碎片的存在，导致数据库的磁盘 I/O 操作变成离散随机读写，加重了磁盘 I/O 的负担。

清理办法：

• MyISAM：optimize table 表名；（OPTIMIZE 可以整理数据文件,并重排索引）

• Innodb：

1. ALTER TABLE tablename ENGINE=InnoDB；(重建表存储引擎，重新组织数据)

2. 进行一次数据的导入导出

碎片清理的性能对比：

引用我之前一个生产库的数据，对比一下清理前后的差异。

SQL执行速度：

• select count(*) from test.twitter_11;



修改前：1 row in set (7.37 sec)

修改后：1 row in set (1.28 sec)

结论：

通过对比，可以看到碎片清理前后，节省了很多空间，SQL执行效率更快。所以，在日常运维工作中，应对碎片进行定期清理，保证数据库有稳定的性能。