服务器里面的数据库占的磁盘容量满了，有什么方法可以继续使用？删除还是收缩？

磁盘容量满
看一下是sql日志占满了，还是磁盘有其它可以删除的文件。主管知道哪些文件是可以删除的。这个要他说，主管一般会给你说的，这些不说的话你就闲着，他不想让你接触重要数据， 一旦删除错了，首先主管的责任，所以他有担心你的技术和 *** 作的。慢慢他会给你说哪些可以删除，哪些不可以删除
LOG很大的话可以收缩一下数据库释放一些空间。
天互数据 杜超为您解答，希望能帮到你

对于包括Exchange在内的绝大多数应用来说，“越大越好”一说总是适用的。即便有几TB的硬盘做高可用，Exchange服务器依然可以吃掉其中大量的空间。不然的话，一旦磁盘剩余空间低于Exchange预设的阀值引起反压，两个邮件客户端的通信将会变得非常迟缓。因此为避免邮件服务的终端，Exchange2013的邮箱服务器开始支持动态磁盘，不过微软声称基本磁盘还是优先选择的对象。在基本磁盘的前提下，Exchange的专家们想尽了一切可以扩大磁盘空间的办法。大致有如下几种：1 通过Exchange归档 — 这是压缩邮箱大小同时又不删除任何数据的好办法，不过需要另一个邮箱数据库用作存储（这里不讨论PST归档）。当然服务器依旧会磁盘耗尽，然后你就需要买新的Exchange的License以满足空间规划需求。2 通过使用多个数据库 –Exchange 2010在性能及磁盘利用率上有很大提高。它给许多组织提供了将邮箱部署在廉价磁盘上的机会。上述两点并没有完全满足Exchange服务器的磁盘需求。那么以下会讨论更加常用的方法：a 通过删除所有数据库中的数据：最简单的办法当然是删数据，当然你会注意到删除公用文件夹以及邮箱数据后，数据库的大小并不会减少；你还需要执行离线碎片清理。当然离线碎片清理初始化阶段会要求Exchange创建一个临时数据库，这需要额外的空间。然后在清理过程中，主数据库副本会将数据拷贝到临时数据库。简单地说，整个过程中都需要额外的磁盘空间。离线碎片整理的命令如下：ESEUTIL /D <数据库名>b 通过调整恢复限制：另一个好办法是调整邮箱数据库限额，步骤如下：1 打开Exchange管理中心，选择左侧“服务器”标签，然后选择上方“数据库”标签页。2 选择数据库，单击上方“编辑”图标，选择“限制”3 在限制会话框中可以调整删除项目以及删除邮箱的保留天数，调整这些限制就可以获得一些临时空间。c 通过更改数据库路径：在很多情况下，恢复磁盘空间最有效的办法莫过于调整数据库路径。尤其是在多个数据库的位置放在一个卷下的时候。你可以将数据库移至空闲磁盘来为当前磁盘腾出空间。d 执行数据库维护模式：Exchange服务器会定期执行维护模式（通常在晚上）以保持数据库健康。在一次维护中，系统主要执行了以下 *** 作：1 数据库碎片整理2 数据库检查点文件校验3 页面修复（Page Patching）4 页面清零（Page zeroing）5 清理Dumpster（即缓存）6 公用文件夹过期7 被删除邮箱的空间释放此外，由于维护过程经常会超时，你需要检查服务器日志来确定维护是不是已结束。如果你发现在计划的窗口中没有完成，你可能需要调整计划以确保维护过程有足够的时间。注意：在在线碎片整理过程中，从数据库回收的碎片不会释放为磁盘空间，只有离线碎片整理会释放空间。

-- 清空日志
--压缩日志及数据库文件大小

/--特别注意
请按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的数据库
--/
selectfromsysfiles
--1清空日志
DUMPTRANSACTIONusernameWITHNO_LOG

--2截断事务日志：
BACKUPLOGusernameWITHNO_LOG

--3收缩数据库文件(如果不压缩,数据库的文件不会减小
-- 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

-- 也可以用SQL语句来完成
--收缩数据库
DBCCSHRINKDATABASE(username)

--收缩指定数据文件,1是文件号,可以通过这个语句查询到:selectfromsysfiles

DBCCSHRINKFILE(2)

--4为了最大化的缩小日志文件(如果是sql70,这步只能在查询分析器中进行)
-- a分离数据库:
-- 企业管理器--服务器--数据库--右键--分离数据库

-- b在我的电脑中删除LOG文件

-- c附加数据库:
-- 企业管理器--服务器--数据库--右键--附加数据库

-- 此法将生成新的LOG，大小只有500多K

-- 或用代码：
-- 下面的示例分离username，然后将username中的一个文件附加到当前服务器。

execsp_dboptionusername,'singleuser',true
a分离
EXECsp_detach_db@dbname='username'

b删除日志文件
execmasterxp_cmdshell'delD:\ProgramFiles\SQL\database\username_LOGldf'

c再附加
EXECsp_attach_single_file_db@dbname='username',
@physname='D:\ProgramFiles\SQL\database\username_DataMDF'

--5为了以后能自动收缩,做如下设置:
-- 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"

--SQL语句设置方式:
EXECsp_dboption'数据库名','autoshrink','TRUE'

--6如果想以后不让它日志增长得太大
-- 企业管理器--服务器--右键数据库--属性--事务日志
--将文件增长限制为xM(x是你允许的最大数据文件大小)

--SQL语句的设置方式:
alterdatabase数据库名modifyfile(name=逻辑文件名,maxsize=20)

分类: 电脑/网络 >> 硬件
问题描述:

我们都知道现在电脑的瓶颈出现在硬盘的读写速度上。所以不管你用多么好的cpu，多么大的内存。在运行某些程序的时候始终有停顿感，这就是硬盘的读写速度跟不上cpu和内存的节奏。磁盘阵列无疑是缓解这一矛盾的有效方法。我想问下，现在桌面平台提供的RAID 0/1/0+1/5,他们具体是什么意思。

解析:

RAID

1 RAID是由美国加州大学伯克利分校的DAPatterson教授在1988年提出的。RAID 是Redundent Array of Inexpensive Disks的缩写，直译为"廉价冗余磁盘阵列"，也简称为"磁盘阵列"。后来RAID中的字母I被改作了Independent，RAID就成了"独立冗余磁盘阵列"，但这只是名称的变化，实质性的内容并没有改变。可以把 RAID理解成一种使用磁盘驱动器的方法，它将一组磁盘驱动器用某种逻辑方式联系起来，作为逻辑上的一个磁盘驱动器来使用。一般情况下，组成的逻辑磁盘驱动器的容量要小于各个磁盘驱动器容量的总和。RAID的具体实现可以靠硬件也可以靠软件，Windows NT *** 作系统就提供软件RAID功能。RAID一般是在SCSI磁盘驱动器上实现的，因为IDE磁盘驱动器的性能发挥受限于IDE接口(IDE只能接两个磁盘驱动器，传输速率最高15MBps)。IDE通道最多只能接4个磁盘驱动器，在同一时刻只能有一个磁盘驱动器能够传输数据，而且IDE通道上一般还接有光驱，光驱引起的延迟会严重影响系统速度。SCSI适配器保证每个SCSI通道随时都是畅通的，在同一时刻每个SCSI磁盘驱动器都能自由地向主机传送数据，不会出现像IDE磁盘驱动器争用设备通道的现象。

RAID的优点
成本低，功耗小，传输速率高。在RAID中，可以让很多磁盘驱动器同时传输数据，而这些磁盘驱动器在逻辑上又是一个磁盘驱动器，所以使用RAID可以达到单个的磁盘驱动器几倍、几十倍甚至上百倍的速率。这也是RAID最初想要解决的问题。因为当时CPU的速度增长很快，而磁盘驱动器的数据传输速率无法大幅提高，所以需要有一种方案解决二者之间的矛盾。RAID最后成功了。

可以提供容错功能。这是使用RAID的第二个原因，因为普通磁盘驱动器无法提供容错功能，如果不包括写在磁盘上的CRC (循环冗余校验) 码的话。RAID 和容错是建立在每个磁盘驱动器的硬件容错功能之上的，所以它提供更高的安全性。

RAID的另一特征是具备数据校验(Parity)功能，校验可被描述为用于RAID级别2，3，4，5的额外的信息，当磁盘失效的情况发生时，校验功能结合完好磁盘中的数据，可以重建失效磁盘上的数据。对于RAID系统来说，在任何有害条件下绝对保持数据的完整性(Data Integrity)是最基本的要求。数据完整性指的是阵列面对磁盘失效时保持数据不丢失的能力，由于数据的破坏通常会带来灾难性的后果，所以选择RAID阵列的基础条件是它能提供什么级别的数据完整性。

2 RAID比起传统的大直径磁盘驱动器来，在同样的容量下，价格要低许多。RAID

的分级

RAID 0级(Stripe) ：无冗余无校验的磁盘阵列 数据同时分布在各个磁盘驱动器上，没有容错能力，读写速度在RAID中最快，但因为任何一个磁盘驱动器损坏都会使整个RAID系统失效，所以安全系数反倒比单个的磁盘驱动器还要低。一般用在对数据安全要求不高，但对速度要求很高的场合。

RAID 1级(Mirror) ：镜象磁盘阵列 每一个磁盘驱动器都有一个镜像磁盘驱动器，镜像磁盘驱动器随时保持与原磁盘驱动器的内容一致。RAID1具有最高的安全性，但只有一半的磁盘空间被用来存储数据。主要用在对数据安全性要求很高，而且要求能够快速恢复被损坏的数据的场合。

RAID 1+0 ：如果同时对RAID 0中写往两个硬盘的数据再做两个镜像如何呢？这就是RAID 1+0的方案。RAID 1+0至少使用4个硬盘，这样，RAID 1+0在理论上同时保证了RAID 0的性能和RAID 1的安全性，代价是比RAID 0 或1再多一倍的硬盘数量。但应该注意，这仅仅是理论上的，因为实际中IDE RAID 这样的软件RAID系统会消耗CPU运算时间，RAID 1+0比起RAID 0或1来讲，同样多消耗一倍的CPU时间，所以性能最后不一定能提升到RAID 0那样的比例，甚至有可能总体性能不升反降。

RAID 3 ：任何一个单独的磁盘驱动器损坏都可以恢复。RAID3和RAID4的数据读取速度很快，但写数据时要计算校验位的值以写入校验盘，速度有所下降。RAID3和RAID4的使用也不多。

RAID 5级 ：无独立校验盘的奇偶校验磁盘阵列 同样采用奇偶校验来检查错误，但没有独立的校验盘，校验信息分布在各个磁盘驱动器上。RAID5对大小数据量的读写都有很好的性能，被广泛地应用。

从RAID1到RAID5的几种方案中，不论何时有磁盘损坏，都可以随时拔出损坏的磁盘再插入好的磁盘(需要硬件上的热插拔支持)，数据不会受损，失效盘的内容可以很快地重建，重建的工作也由RAID硬件或RAID软件来完成。但RAID0不提供错误校验功能，所以有人说它不能算作是RAID，其实这也是RAID0为什么被称为0级RAID的原因--0本身就代表"没有"。

3 RAID 的应用

当前的PC机，整个系统的速度瓶颈主要是硬盘。虽然不断有Ultra DMA33、 DMA66、DMA100等快速的标准推出，但收效不大。在PC中，磁盘速度慢一些并不是太严重的事情。但在服务器中，这是不允许的，服务器必须能响应来自四面八方的服务请求，这些请求大多与磁盘上的数据有关，所以服务器的磁盘子系统必须要有很高的输入输出速率。为了数据的安全，还要有一定的容错功能。RAID 提供了这些功能，所以RAID被广泛地应用在服务器体系中。

4 RAID 提供的容错功能是自动实现的(由RAID硬件或是RAID软件来做)。

它对应用程序是透明的，即无需应用程序为容错做半点工作。要得到最高的安全性和最快的恢复速度，可以使用RAID1(镜像)；要在容量、容错和性能上取折衷可以使用RAID 5。在大多数数据库服务器中， *** 作系统和数据库管理系统所在的磁盘驱动器是RAID 1，数据库的数据文件则是存放于RAID5的磁盘驱动器上。

5 有时我们看某些名牌服务器的配置单，发现其CPU并不是很快，内存也算不上是很大，显卡更不是最好，但价格绝对不菲。是不是服务器系统都是暴利产品呢？当然不是。服务器的配置与一般的家用PC的着重点不在一处。除去更高的稳定性外，冗余与容错是一大特点，如双电源、带电池备份的磁盘高速缓冲器、热插拔硬盘、热插拔PCI插槽等。

另一个特点就是巨大的磁盘吞吐量。这主要归功于RAID。举一个例子来说，一台使用了SCSI RAID的奔腾166与一台IDE硬盘的PIIICopermine 800都用做文件服务器，奔腾166会比PⅢ的事务处理能力高上几十倍甚至上百倍，因为PⅢ处理器的运算能力根本用不上，反倒是奔腾166的RAID起了作用。

6 RAID现在主要应用在服务器，但就像任何高端技术一样，RAID也在向PC机上转移。也许所有的 PC 机都用上了SCSI磁盘驱动器的RAID的那一天，才是PC机真正的"出头之日"。

如果您查询Hadoop磁盘时发现全部为0，可能是以下原因之一：
1 您的Hadoop集群中还没有数据被写入：在Hadoop集群中，如果没有进行数据写入 *** 作，磁盘使用率就会为0。
2 您查询的是没有数据块分配的磁盘：在Hadoop中，数据会被分成若干个数据块并存储到不同磁盘的不同节点上。如果您查询的磁盘没有分配到数据块，它的使用率也会为0。
3 硬盘损坏：如果硬盘损坏，Hadoop就无法在该硬盘上进行数据的读写 *** 作，因此该磁盘的使用率也会为0。
如果您确定数据已经写入到Hadoop中，并且磁盘的使用率仍然为0，可以通过检查Hadoop相关配置、HDFS NameNode和DataNode的运行状态及日志信息等方式来判断问题所在。您也可以尝试重新启动Hadoop服务并重新查询磁盘使用率，看是否能够正常显示。

Urchin 的报告数据存储在各个配置文件所独有的每月数据库中(注：Urchin分析后的数据是按月归档)，这些数据库一般位于 Urchin 的 data/reports 目录下。每个配置经过处理的数据库大小为原日志大小的5% 至10%。

默认情况下，Urchin 会保留每月的这些配置文件数据库，但经过长时间的数据积累数据量会变大，导致Urchin处理后的数据占用空间越来越大，并且在用户查看时也会降低Urchin的响应效率。因此，需要优化Urchin 配置文件每月数据库的磁盘存储空间。

优化 Urchin 配置文件每月数据库的磁盘存储空间的方法通常有以下五种：

1将配置文件设置为，在处理日志后自动删除原始跟踪数据

2设置配置文件以存档历史记录数据

3限制保留历史记录报告数据的月份数。

4压缩配置文件数据库。

5合理设置数据库自动备份。

方法 1：在处理日志后，删除原始跟踪数据

可对配置文件加以配置，以便在处理完成后删除原始访问者和会话信息。这可改善大型网站的性能，降低所存储的数据量。请注意：选择此配置后，跨日期的会话会显示为两个会话(一天一个会话)，而不是一个会话。对大部分网站来说，结果中的差异可以忽略不计。

对配置文件加以配置，以便在处理完成后删除原始访问者和会话信息：

1在管理界面中，点击”配置”，然后再点击”Urchin 配置文件”–》”配置文件”。

2修改所需配置文件。

3在”存储/数据库”标签中，将”保留原始跟踪数据”字段设为”关闭”。

4点击”更新”。

方法 2：自动存档历史记录数据

可对配置文件加以配置，将每月历史记录数据压缩到存档文件中。报告可以查看存档的数据，但不会再为已存档的月份处理额外的点击。

对配置文件加以配置以存档历史记录数据：

1在管理界面中，点击”配置”，然后再点击”Urchin 配置文件”–》”配置文件”。

2修改所需配置文件。

3在”存储/数据库”标签中，将”存档数据库”字段设为”打开”。

4为”在此后存档数据库”字段指定月份数字(此选项指定数据保留多少个月后开始自动存档)。

5点击”更新”。

方法 3：定期移除不用的配置文件数据

Urchin配置文件data/reports/profile-name”目录下的数据是可以移动的，因此对于不使用的数据信息定期移除移除即可。这是最简单直接的方法，建议通过自动脚本实现。

方法 4：压缩配置文件数据库

将旧的 Urchin 每月数据库压缩所产生存档的大小一般只有未压缩前数据库集的 20% 到 30% 左右。虽然 Urchin 报告引擎无法直接读取 ZIP 存档，但它可随时从 ZIP 存档中提取所需数据库。报告引擎不会删除已解压缩的数据库，这可提高用户查看 Urchin 报告时对数据的访问速度。不过，原始的 ZIP 存档会保留在原处，因此定期清除 *** 作可直接删除解压缩后的数据库，以重新获取磁盘空间。

方法5：合理设置数据库自动备份

数据库备份和清除功能提供了对配置文件备份信息的设置：

1启用自动回滚数据库，如果处理过程中途停止或中断，数据可以自动得到修复。Urchin 会自动检测到这种情况并将数据回滚到最近的备份(如果有)，然后再继续。

2清除备份，使用此选项可以根据需保留在下一选项中的备份的数量，自动清除以前的备份。如果启用此功能，Urchin 将自动删除以前的备份，以控制存储量。

3要保留的备份数，此选项可为上述清除功能指定每月保留的备份数量。

通常从优化服务器占用空间的角度考虑会关闭备份所有功能，但从配置文件运行安全角度考虑，可以启用备份功能。
Urchin 数据库存储技术概述

对于每个 Urchin 配置文件，Urchin 会在名为 YYYYMM(年月) 的目录下，维护每月存储的一组数据库文件。这些目录分别包含约 50 个为报告引擎提供数据的文件。这些目录和数据库文件以其存储数据的月份来命名。完整的数据库列表是：

YYYYMM-uhed –> 数据库标头

YYYYMM-usti –> 字符串索引

YYYYMM-ustd –> 字符串数据

YYYYMM-udai –> 汇总表索引

YYYYMM-udXX –> 汇总数据表(XX 由数据地图的表编号替换)。

YYYYMM-uvii –> 访问者索引

YYYYMM-uvid –> 访问者数据

YYYYMM-used –> 会话数据

YYYYMM-upad –> 路径数据

YYYYMM-utrd –> 交易数据 (Ecommerce)

YYYYMM-uitd –> 项目数据 (Ecommerce)

YYYYMM-ulti –> 日志跟踪索引

YYYYMM-ultd –> 日志跟踪数据

YYYYMM-utod –> 总计数据

YYYYMM-uhid –> 柱状图数据

YYYYMM-umad –> 访问者矩阵数据

每一组数据库对于所包含数据的月份来说都是完整的。因为每月的数据库集之间并无相关性，因此可对每个数据库集独立进行存档和修剪 *** 作，其他月份的数据不会受到影响。

正常 *** 作下会保留每个月的整套月份数据库文件。不过，Urchin 日志处理引擎只会使用这些数据库文件的 4 个文件。这些数据库文件是：

YYYYMM-usti

YYYYMM-udai

YYYYMM-ulti

YYYYMM-ultd

Urchin 日志处理引擎会使用下列数据库文件处理跨群体和访问者深入查看报告。删除这些内容仅会影响到这些报告功能。

YYYYMM-uvii

YYYYMM-uvid

YYYYMM-used

YYYYMM-upad

YYYYMM-utrd

YYYYMM-uitd

这些数据库包含有关访问者、会话、路径、交易和产品的信息。这些文件会使用当月所需总存储空间的某个百分比，大约 10% 到 50% 左右。因此，如果将”配置文件配置”的”存储/数据库”屏幕的”保留原始跟踪数据”选项设为关闭的话，即可赢得较大的磁盘空间。

建议只有访问量极高、保留原始跟踪数据会造成磁盘或 CPU 资源消耗问题的网站，才停用”保留原始跟踪数据”选项。

文章来源：搜索营销艺术

---