【发布时间】：2010-09-17 10:23:42
【问题描述】：
当我转储一个 Sybase 数据库时，表中是否有数据似乎并不重要，文件大小是相同的。有人告诉我，这是因为我的转储文件是二进制而不是逻辑的，因此转储文件的文件基于数据库的分配大小。我知道 Oracle 可以使用逻辑转储文件，但我可以让 Sybase 做类似的事情，还是有任何其他偷偷摸摸的方法来减小转储文件的大小？
【问题讨论】：
【发布时间】：2010-09-17 10:23:42
【问题描述】：
如果您已经在使用 compress_level 9 并且仍需要更多压缩，则可以使用 bzip2 重新压缩文件。
如果您只是对压缩文件进行 bzip2 压缩，您将获得约 10% 的改进。如果您解压缩并重新压缩，您可能会看到 30% 范围内的改进。但请记住，您必须再次解压缩和/或 gzip 文件，以便 Sybase 加载它。
gunzip -c pubs_1.dmp | bzip2 > pubs.dmp.bz2
【讨论】：
从版本 12 左右开始，您已经能够在 ASE 中执行压缩转储。
The syntax is:dump database database_name to file_name [with compression=compress_level]
compress_level 为 0-9。 0 为无压缩，9 为最多。运行转储时压缩的越多，CPU 使用率就越高。您只需执行一些测试即可找到大小与性能之间的适当平衡。
加载转储不需要特殊命令。
【讨论】：
-
这很好用，它的好处是截断我不需要作为转储一部分的表现在会产生效果，因为压缩转储的过程会挤出以前占用的任何空间由空桌子！谢谢亚当！
虽然上面的链接（语法是）显然是正确的，因为它指向 sybase 文档，但 cmets 具有误导性。
简单格式的语法是：
将数据库 {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 处理{积分获得}。如果这是生产主机，我会将文件发送到另一台主机并执行此操作。资源消耗可能相当大。
【讨论】：
-
两种方法都有效。文档表明“with compression=compress_level”是较新且首选的语法。 “旧的 compress:: 选项仅适用于本地存档；您不能使用 servername 选项。要压缩到远程计算机，您必须使用首选 compress=compress_level 选项。”