binary - 有什么方法可以减小 Sybase 数据库的转储文件大小？

Question

当我转储一个 Sybase 数据库时，表中是否有数据似乎并不重要，文件大小是相同的。有人告诉我，这是因为我的转储文件是二进制而不是逻辑的，因此转储文件的文件基于数据库的分配大小。我知道 Oracle 可以使用逻辑转储文件，但我可以让 Sybase 做类似的事情，还是有任何其他偷偷摸摸的方法来减小转储文件的大小？

Answer 1

如果您已经在使用 compress_level 9 并且仍需要更多压缩，则可以使用 bzip2 重新压缩文件。

如果您只是简单地 bzip2 压缩文件，您将获得约 10% 的改进。如果您解压缩并重新压缩，您可能会看到 30% 范围内的改进。但请记住，您必须再次解压缩和/或 gzip 文件，以便 Sybase 加载它。

gunzip -c pubs_1.dmp | bzip2 > pubs.dmp.bz2

Answer 2

从版本 12 左右开始，您已经能够在 ASE 中执行压缩转储。

语法是： dump database database_name to file_name [ with compression=compress_level]

compress_level 为 0-9。0 为无压缩，9 为最多。运行转储时压缩的越多，CPU 使用率就越高。您只需要执行一些测试即可找到大小与性能的适当平衡。

加载转储不需要特殊命令。

Answer 3

虽然上面的链接（语法是）显然是正确的，因为它指向 sybase 文档，但注释具有误导性。

简单格式的语法是：

将数据库 {database_name} 转储到“compress::{#compression_level}::{stripe_device}”

例如：将数据库 mydb 转储到“compress::1::/sybase_dumps/mydb_17022009”

在加载数据库转储方面 ::compress; 需要再次给出选项。

例如。从“compresss::/sybase_dumps/mydb_17022009”加载数据库 mydb

请注意，不需要压缩级别，也不需要额外的分隔冒号。

找到平衡的测试是一个好点，记住你走的越高，预计转储需要的时间就越长。我发现1-3绰绰有余，我从来没有超过6，收益递减不值得。

如果我很绝望，我会按照上面的描述对文件进行 bzip2 压缩{点收入}。如果这是生产主机，我会将文件发送到另一台主机并执行此操作。资源命中可能相当大。