与1C一起使用时，我的IBM DB2 Express-C管理经验：企业

我有机会使用IBM DB2。 在1C和Django上的服务器上，一次都使用了此DBMS，它处理OLAP请求的速度非常快（尽管必须手动配置索引，当然也需要配置Web服务器的索引，这样才能在2秒内响应）。 在2015年，我为自己准备了这个小指导，以免忘记。 作为简历的补充，也许有人在纸上阅读，剩余的工作时间都闲着。 我对DB2经验的一些概括。 我进行了一些更正，建议在这里阅读以扩大视野。 也许有人会感兴趣。 我必须马上说，从那时起我就没有使用DB2，一切都被遗忘了，但是我仍然记得一些东西。 批评和澄清是值得欢迎的，但是由于我不再工作了，也许对我来说不是，而是对其他人有用。

互联网上有许多说明如何使用IBM DB2 DBMS来组织1C：企业版的工作。 对于初学者来说，这一点还不错，但不足以用于生产中。 以前，我建议从IBM DB2开始学习大数据大学DB101RU培训课程。 我本人参加了这门课程，并在2012年通过了考试，我认为这非常有用。 可惜资源不复存在了。 在新平台上，我没有找到类似的东西。 在生产中，IBM DB2需要额外的配置和维护，其中最必要的内容将在此处进行简要描述。 我们正在考虑针对Windows版本10.1fp2和10.5fp4的IBM DB2 Express-C的免费版本（第一个在测试模式下受1C支持，第二个得到正式支持，可惜只支付了较新的版本）。 当使用包含固定大小的长字符串的复合类型时，在对RAM（速度的缓冲区大小）或记录大小（EXTENDED_ROW_SZ = ENABLE）有很高要求的地方，安装64位10.5是有意义的。

要做的第一件事是切换到使用归档日志，以便在不中断1C：Enterprise操作的情况下进行备份，并能够在任何时间点还原数据库（由于未经更正，还原到10.1fp2具有其自身的特点。免费版本中的错误-需要手动移动日志文件）。 与MS SQL不同，日志归档不是在某些预定时间点进行的（在MS SQL中不是很强，也许还有其他东西），并且当日志文件达到一定的预定大小时，无需在还原操作之前备份日志，只是停用基地。 可以轻松配置两个方向的日志记录，例如，其中一个位于网络驱动器上。 而且，在网络中断很短的情况下，活动日志占用的空间不会显着增加。 对于活动日志，您必须提供足够的可用空间以能够在任何给定时间还原数据库。 如果在程序员使用1C基础的过程中，需要在各个接近的时间点频繁返回，一次备份足以恢复，那么选择用于恢复的日志文件就非常简单。 确保在实例开始时激活数据库，否则我们将获得大量带有隐式激活的小型日志文件。 显然，您应该设置备份存储时间（在我看来，您需要存储日志至少两个月）并配置自动删除。 基本备份和备份（日志）必须位于不同的物理磁盘上，在极端情况下，您可以将备份备份到本地网络上的另一台计算机上。

出于其他原因，也需要激活底座。 为了正常运行，您应该安装Windows联机和脱机维护。 此时，该基座应该处于活动状态。 您应该定期查看数据库的历史记录，以了解在脱机窗口期间执行了哪些操作。 离线维护窗口很可能应该在22:00-0:00之间设置，因为此时没有繁重的1C维护任务。 也许对于小型基地而言，持续1小时的窗户就足够了。

您需要定期检查手动模式下是否需要重新组织，并在分析表和索引的状态之后，对单个对象进行重新组织。 手动重组数千个表和索引可能需要很长时间。 使用regexp的简单过滤器（例如，在.js上）可轻松加速分析。

当然，必须定期进行AUTOCONFIGURE，手动校正各个设置，例如，设置自己的日志文件大小。

一天之后，有可能并且更经常地执行数据库的在线备份（不需要关闭并且不需要DBA），频率取决于所需的恢复时间，而恢复时间又取决于最后一次备份后已归档日志文件的数量，即数据库的负载。 对于中型，大型和高负载数据库，使用各种类型的增量备份以减少备份所占用的空间并减少备份的恢复时间是有意义的。 在每次备份之后和还原之前，请检查备份的运行状况。 备份存储时间由DBA决定，但不得少于日志的存储时间。

每月至少一次执行脱机和联机数据库运行状况检查（在脱机模式下，使用数据库的操作将暂停几分钟），并在必要时进行维修（对于不使用UPS的“服务器”而言最重要）。 每月执行数据库的脱机备份，因为脱机备份将被保存很长时间，因为当您更改DB2的版本时，将无法部署联机备份。 如果“ 1C：企业”甚至不允许短期脱机转换数据库以进行验证或备份，则可以在数据库的扩展副本中执行指示的操作。 数据库可以从备份还原到另一个位置，而不会出现任何问题，例如，还原到另一台服务器上的另一个磁盘。 应该注意的是，备份和归档日志都可以使用DB2工具进行压缩（在这种情况下，备份验证工具保持功能，归档日志验证工具不起作用）。

脱机检查数据库和脱机备份之前，应将数据库和计划任务设置为锁定状态。 在紧急情况下，您可以稳定数据库，但是由于SYSADM_GROUP组中包含运行1C：企业服务器的用户，因此这不会取消在错误的时间将1C连接到数据库的功能，因此，需要重新启动数据库。职位发布。

如果数据库无法快速运行，则在更新统计信息之后，您应该获得最严格的查询计划，在数据库副本中试验1C索引，在IBM Data Studio中监视对查询计划的更改（在这种情况下，使用eclipse是合理的，在其他情况下，与命令界面足够了行），或使用DB2 Design Advisor的建议，并在必要时在1C之外手动创建索引。 同时，开始使用DB2工具（十多个SQL脚本）收集详细的性能信息，并使用系统监视器分析负载。 为了减少磁盘系统的负载，必须将数据库安装在足够大的单独高速磁盘上（当然，除非可以使用普通的RAID 10服务器磁盘阵列），否则可以将活动日志与操作系统一起放置在SSD上。 可能还需要更改1C：企业服务器的速度位置。 如果仅计划购买磁盘，则对于小型组织而言，可以临时将单个物理磁盘用于数据库。

每天都要检查db2diag.log上的错误以及数据库操作的结果。 达到数十兆字节的大小时进行存档。 Far Manager是查看日志的一种便捷方法（假定数据库中几乎没有错误），如果您需要手动移动存档日志以在某个时间点还原，则Far Manager也会有所帮助。

在我看来，IBM DB2的竞争优势之一可以被认为是，在MS SQL Server要求64位1C：企业服务器正常运行的情况下，IBM DB2可以使用32位。

UPD：也许，在发布之前检查1C：Enterprise支持的DB2版本时，他并不小心。 在2015年本文的原文中，大约有10.5fp4的字样：与1C：Enterprise一起使用时，“尚未检测到错误”。 也就是说，目前，新的Express-C仅支持10.1（具有其功能和局限性）。 在今天的付费中，只有11.1得到官方支持。 某人可能拥有足够的Developer-C，并且数据库大小最多为100 GB。 我没有更改文档的链接-可以轻松切换到该文档。

UPD：我重新阅读了所有内容，也许对使用DB2的人来说应该很清楚，但是例如，对于那些刚接触此DBMS的人来说，可能需要澄清一下

应该查看基地的历史

也应该带到这里

执行离线和在线数据库运行状况检查

这里 ， 这里和这里 ，但是在后一种情况下，可能已经需要
这就是

使用regexp的简单过滤器（例如，在.js上）可轻松加速分析。

可能会引起困难，我不确定是否有人这样做，是否依赖于自动化，最大值仅限于此查询： db2 "SELECT substr(TABSCHEMA,1,20), substr(TABNAME,1,20) FROM SYSIBMADM.ADMINTABINFO WHERE REORG_PENDING = 'Y'"但是接下来，分析描述并开始对所选对象的重新组织或增加离线维护窗口。 经过几次迭代后，很明显哪些对象没有进行重组。
我希望我不要混淆任何事情，我整理了五年的剧本档案，可能是处方书。 我不知道这个补充对所有人是否有用。

链接到提到的资源/文件

除了在不再存在的课程中获得的信息之外，还可以在此处找到基本信息（然后链接是不同的）。

已经忘记了很多东西，但是有一个指向pdf文档“最佳实践。 找到了“调整和监视数据库系统性能” （链接现在是新的，从2020年1月1日起，旧的Wiki就不复存在了，但是到目前为止，一切还不太稳定）。