采用集中上载方式的非线性制作网的若干细节归纳

    •  由于 MAV70 录入的最短素材文件至少为 10 秒，总会有用户录入少于十秒的素材，或是做了其他的非法上载操作，使得 MAV70 将这些上载的素材文件作为“垃圾”文件，而不作处理，一些转码失败的素材也会堆积起来，久之，这样的素材条目不仅占用了 MAV70 相当的空间容量，还会在上载数据库中产生许多“垃圾”信息，对于今后管理人员查找、整理信息也会是个不大不小的麻烦。所以管理人员应定期通过集中上载主程序进行管理和清除。

    •  MAV70 视频服务器作为传统的视频设备，同步源的输入是其能够正常工作的前提，因此在素材上载前，特别是定时任务执行前，一定要保证正确的同步输入。

    •  记得一次， MAV70 的 PU 板（位于 MAV70 系统内部，专用于磁盘校验工作的板卡）报“日志已满，日志错误”的警告，当然这对于 MAV70 而言，只是一个并不影响正常工作的警告，笔者通过专用软件可以看到，确实报该板的日志错误。但无论笔者如何想将该 PU 板的错误日志清除，均告失败，管理工具提供的所有清除命令无任何效果。不得已，笔者趁一次周末夜间，无上载工作时，将 MAV70 的磁盘带区集进行了重建，重建完成后原先的所有磁盘信息全部清除，错误日志自然也不复存在了。

    •  某次值夜班时，有编辑来告之笔者，说他在上载时报一打不开数据库的对话框，初听以为是他的误操作或集中上载部分出现了故障造成的。在笔者进入机房后，几个在线的编辑也说正在做节目时也弹出一数据库连接失败的对话框。既然是集中上载与制作网同时报与数据库有关的故障信息，笔者的第一判断就是数据库可能出现了问题。笔者在中心服务器机房发现，域控制器群集已做了自行切换，但数据库服务并未启动。看来问题不大，笔者手动将域控制器群集切回原有的服务器（笔者的习惯），手动启动了数据库服务，一切似乎已经正常，事情看起来不是很复杂。就在我还正想着怎么会无故发生自动切换这种“怪事”时，编辑又来找我了……现象依旧，唯有所不同的是群集的切换在群集管理器判定原镜像机也出现故障后，重新试图启动原主控机。此时数据库也在时断时续地响应着网络中的请求。这是一个比较少见的现像，无论我如何重启整个网络、修复数据库、还原已备份的数据库，所有尝试均告失败。这时我将注意力放至了数据库群集，也许就是这里的原因。在备份了现有的数据库后（虽然它已经没什么用了），卸载并重新安装了数据库群集，运转正常了。笔者重建了所有的网络用户的信息。当时是在网络的试运行期间，也幸好是在试运行期间，现在笔者又要到哪里去找这样一个环境来做这样一个“实验”？但是为什么出现了数据库群集的崩溃，笔者至今也未能找出恰当的解释。

    •  一次，在重启一台带光卡（ FC 卡）的工作站时，在开机时报磁盘（为 MDC 服务器的卷标）故障，磁盘进行扫描，并报错。由于当时有某种原因，该工作站连续重启数次，每次均正常关机，每次均检测。报错的同时要求对卷进行 CHKDSK.exe 操作。这引起了笔者的注意，对其他带光卡的工作站重启，出现同样的现象。通过 SANergy 软件对磁盘阵列测试后，未发现任何问题。分析后认为，造成故障的原因应与 MDC 服务器操作系统下的卷数据结构有关，重启 MDC 服务器后，问题不再出现。

    •  另一个和 MDC 有关的问题是，在原先的新闻制作网中，主域控制器与 MDC 服务器合在一起，所有的网络控制均由主域控制器发出。由 MDC 服务器的工作原理可知，这是性质比较特殊的一类服务器，一方面它的地位非常重要，另一方面它的 I/O 流量相对较小。因此，是否有必要将其分开呢？在这次建网的过程中，对原有的新闻网进行了部分升级，其中就包括了加入独立的 MDC 服务器。事实证明，独立的 MDC 服务器可以使稳定性有很大的提高。由此可见，虽然 MDC 服务器的 I/O 流量相对较小，但主域控制器的网络负担任何的加重，都会对全网产生很大的影响。