一个关于DUMP 的问题请教大家!

qjhadm

我系统运行环境: ASE12.5 +WINDOWS 2000

数据库中的主要表为ImgFile(表名),大约有几十张.

每个表的结构如下:

CREATE TABLE dbo.ImgFile2
(
    AchvsID        char(25)    NOT NULL,
    DiskNum        int         NULL,
    ImgFile        char(40)    NOT NULL,
    PageClass1     text        NOT NULL,
    PageClass2     text        NULL,
    PageSum        int         NOT NULL,
    AlterSubType   char(100)   NULL,
    ElseSubType    char(10)    NULL,
    ValidDate      datetime    NOT NULL,
    CompanyID      int         NOT NULL,
    CompanyType    int         NOT NULL,
    CancelGroupID  char(10)    NULL,
    CompanySubType int         NOT NULL,
    AchvsMainType  char(50)    NOT NULL,
    AchvsContent   text        NOT NULL,
    WorkingDate    datetime    NOT NULL,
    JNMLBM         char(20)    NOT NULL,
    SubType        char(255)   NULL,
    BatNo          int         NULL,
    BGHRegistID    char(20)    NULL,
    BGHCompanyName varchar(80) NULL,
    BGHFRDB        char(20)    NULL,
    WDXZDCFD       int         NULL,
    DATM           char(20)    NULL,
    DAHTM          char(20)    NULL,
    RegionClass    text        NULL,
    BlurPages      text        NULL,
    CopyPages      text        NULL,
    FileToDBFlag   int         NULL,
    CONSTRAINT BACKImgFile2_8320029641
    PRIMARY KEY CLUSTERED (AchvsID)
)
LOCK ALLPAGES
go
=============================================

我用DBARTISAN看到表的情况是这样的,为什么会是这样?




另外每张表的现在的记录也不过一、两万条。可是我
DUMP DATABASE TO ‘D：\DBBAK\DATABASENAME.DAT’

发现我的数据库现在有1个多G的大小。等要我的数据每张表有几十万条时。完全备份的数据库大小还不要上百个G。
另外增量备份我始终感觉不安全，于是我现在每天将数据库完全备份一遍。而后再BCP一遍所有的数据。我的问题来了，真得好麻烦了。以后如何备份始终是困扰我的一个大问题。

unix007

先将日志截断truncate,然后再备份，文件会小一些。

chenfeng825

楼上的说的对，你可以在备份前sp_helpsegment 'logsegment'看看是否log很大。
还有，如果空间紧张，可以使用compress关键字（12.5提供)

chenfeng825

Sorry.开始每仔细看,你的数据库空间有很大问题，data 只有6M，而indexs 380多M，你的table lock schema是allpages lock，建议你重建clustered index和别的索引

qjhadm

谢谢,可是我还没有见过索引啊,据说这些索引其实是我的TEXT字段造成的

具体我也不太清楚,本来想将数据库页面大小设为8K,而后将TEXT字段改为VARCHAR(8000)可是后来一看,有5\6个TEXT字段,结果没有改成.

这些显示的索引真得是索引吗?如何解决空间问题呢?期待中

chenfeng825

你的LOG SEGMENT的几乎是空的。应该是你的TEXT COLUMN引起的。压缩备份吧

qjhadm

不过随之而来,有几个问题还要请教:
1.如何压缩备份,压缩备份是完全备份数据库吗?
2.压缩备份生成的备份文件如何恢复?
3.压缩备份的备份过程所要的时间比普通备份时间要花的时间长吗?

谢谢

chenfeng825

原帖由 "qjhadm" 发表：
不过随之而来,有几个问题还要请教:
1.如何压缩备份,压缩备份是完全备份数据库吗?
2.压缩备份生成的备份文件如何恢复?
3.压缩备份的备份过程所要的时间比普通备份时间要花的时间长吗?

谢谢

   

A1.dump database db_name to compress::x::  /path/file
    x的值从1~9，数字越大压缩越高，速度越慢。
A2.load database db_name from compress::x:: /path/file
A3.是

Blackrose

我来说两句

使用sp_spaceused或者这些工具察看表空间的时候
image 或者 text 的空间大小会统计显示在 index_size 上

qjhadm

那请问有什么办法可以看到实际的index_size and data_size的分布情况及大小呢??

我就是想不通,为什么会这么备份出这么大的数据库,为此我做了以下实验:

实验环境:
同一台计算机操作系统为WINDOWS 2000 SERVER 分别安装了
MS SQL SERVER 2000
SYBASE ASE 12.5  FOR WINDOWS

分别将相同结构的数据库脚本执行到这两种数据库平台上,生成两个结构完全相同的数据库,数据库名为TEST .数据库中大约有二十张左右的表,表的结构见(楼顶),而后分别将以前BCP OUT 出来的备份数据导入这两种数据库,而后分别进行完全备份,得到的结果使我大吃一惊

测试结果如下:   

MS SQL SERVER 2000下完全备份TEST数据库共用时12秒,备份生成的数据库文件大小为54.4M

SYBASE ASE12.5 下完全备份TEST数据库共用时9分钟.备份生成的数据库文件大小为1.15G.(注意,是1.15个G)

为什么会是这样的结果,另人难以置信,


请有关此方面经验的朋友谈谈自已的看法. 我真有点想不透了.我要怎么办?