嗨，Albert。原则上，我看到两种方法：（1）系统复制/基于R3load：使用基于R3load的系统复制工具完成数据库的导出和重新导入。 这是一种离线方法。 理想情况下，您将有第二个数据库主机作为目标，以便与导出和导入重叠，从而节省时间。

16 TB应该在周末可以执行，但是取决于许多因素，例如硬件功能，存储容量 最大的表，...。需要测试。

（2）DB6CONV：这种方法允许在线转换，可以移动完整的表空间，并对每个表空间执行在线逐步过程。

当您打算移动所有内容时，对于这两种选择，您可能还需要考虑将最大的表移动到它们自己的专用表空间中（如果尚未这样做），从而实现平衡的表空间 layout
平衡布局，即具有理想大小相等的多个表空间，通常有助于数据库备份运行时间。

您可能还需要考虑表空间池的概念，该概念旨在实现平衡布局。 有关详细信息，请参见注释" 2267446-DB6：对表空间池的支持"。 和先决条件。

嗨艾伯特，

我基本上同意Hans-Juergen的观点。 使用DB6CONV是有效的选项。 如果决定使用此选项（包括移动表数据），则应了解表空间池的概念。

可能还有第三个选择：

（3）使用8个文件系统创建一个新的存储组，一个接一个地将表空间分配给新的存储组，然后使用REBALANCE将表空间移至新的存储组。

https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.admin.dbobj.doc/doc/t0060303.html

我假设您已经在使用自动存储表空间。 如果没有，您可以将DMS表空间转换为自动存储表空间。

选项（3）不如DB6CONV选项灵活，因为它不允许将表重新分配给新表空间，例如不允许引入表空间池。 但是，由于绕过SQL引擎逐页移动数据，因此速度可能更快。

致谢

弗兰克

大家好，

感谢您对此事的宝贵意见。 关于SAP的数据库体系结构，我仍然是一个新手。 在我们的项目中，我将考虑所有选项。 根据您提到的内容，似乎选项2会是更好的选择，因为我们也在尝试平衡表空间的分配以提高备份性能。 除此之外，由于旧表空间是在DB2 9.5上创建的，因此我们需要将这些表移动到新表空间，因此不允许我们将存储回收回文件系统。 我假设表空间池也将允许将存储空间回收给FS，但是如果我弄错了，请纠正我。

我想从基础架构的角度理解的一件事是，我们如何将对象从当前布局（1个具有6个sapdata子目录的FS迁移，并为每个34个表空间提供一个容器）迁移到目标布局（8个FS 每个34个表空间都有一个容器）？ 我们是否只是创建新的sapdata FS并继续使用旧子目录（即sapdata1，..，sapdata6）中的数字序列（sapdata7，sapdata8），还是我在这里遗漏了其他内容？ 我假设我们不能对新布局使用旧的sapdata数字序列，因为一旦安装了这些FS，它将覆盖目录。

再次感谢您。

祝一切顺利

阿尔伯特

你好，阿尔伯特，你好，弗兰克，

上述方法对我来说很有意义。

也许还有两条评论：

• 对于最大的表，您可以考虑将它们放置在自己的专用表空间中，而不是表空间池中。 在非常不幸的星座中，自动哈希算法（将表分配到池表空间）可能会将两个或多个非常大的表放置在同一池表空间中，因此无法提供最佳的平衡布局。
• 搬家后只拥有sapdata [7-14]很满意，并且喜欢重命名，请查看 db2relocatedb 功能。 这应允许在移动后重命名sapdata。 从功能的角度来看，根本不需要它。 为了优雅起见，这将是一个问题，您是否喜欢sapata计数以" 1"开头。 此外，此程序还应该在测试环境之前进行验证。

最诚挚的问候，汉斯·于尔根

大家好，

感谢您对此的反馈。 我们将研究你们俩提供的选项，并希望使这个项目进展顺利。 看来我们将需要几个月的时间来计划，进行质量检查和进行生产迁移，但是我认为，一旦一切都解决了，我们就应该为我们的ERP系统配备一个更强大的数据库服务器。 谢谢！

祝一切顺利

阿尔伯特