DERBY DB：Random IOException：新服务器平台上的错误文件描述符

时间：2018-08-21 09:45:31

标签： java derby

使用Derby DB时遇到一些问题，不知道我们做错了什么（或者是否做错了）。

我们的客户正在迁移到新的服务器平台。目前，我们已经在其旧服务器平台上运行了多个应用程序，到目前为止，这些应用程序都运行良好。但是在新平台上，自几个月以来，我们和客户一直在分析一些随机的Derby错误，这些错误一直在重复发生。但是，越深入，我们就越无知。

如果有人可以对此进行调查，并给我们一些想法，如果这是derby中的错误，或者您有其他想法可能导致derby如此行事或我们做错了事，我们将很高兴。

情况

我们有一个包含多个嵌入式DERBY数据库的应用程序。服务器启动后，应用程序会在几分钟内正常运行。但是几分钟后，其中一个Derby数据库（由JAVA Hibernate使用DERBY嵌入式模式访问）首先在随机derby文件上显示这样的错误（文件每次都不同）：

Local derby log (/home/tomcat_i36/derby.log):

------------  Begin Shutdown Error Stack -------------

ERROR XSDG3: Meta-data for Container(0, 33904) could not be accessed to clean /opt/apps/tomcat/i36/webapps/XXXXX/database/XX/seg0/c8470.dat
        at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown Source)
        at org.apache.derby.impl.services.cache.ConcurrentCache.cleanAndUnkeepEntry(Unknown Source)
        at org.apache.derby.impl.services.cache.ConcurrentCache.cleanEntry(Unknown Source)
        at org.apache.derby.impl.services.cache.BackgroundCleaner.performWork(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:809)

Caused by: java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileDispatcherImpl.pread0(Native Method)
        at sun.nio.ch.FileDispatcherImpl.pread(FileDispatcherImpl.java:65)
        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
        at sun.nio.ch.IOUtil.read(IOUtil.java:210)
        at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:754)
        at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:739)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.getEmbryonicPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown Source)
        ... 8 more

============= begin nested exception, level (1) ===========

java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileDispatcherImpl.pread0(Native Method)
        at sun.nio.ch.FileDispatcherImpl.pread(FileDispatcherImpl.java:65)
        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
        at sun.nio.ch.IOUtil.read(IOUtil.java:210)
        at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:754)
        at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:739)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer4.getEmbryonicPage(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown Source)
        at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown Source)
        at org.apache.derby.impl.services.cache.ConcurrentCache.cleanAndUnkeepEntry(Unknown Source)
        at org.apache.derby.impl.services.cache.ConcurrentCache.cleanEntry(Unknown Source)
        at org.apache.derby.impl.services.cache.BackgroundCleaner.performWork(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown Source)
        at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:809)

============= end nested exception, level (1) ===========

------------  End Shutdown Error Stack ------------

这种情况发生后，数据库的行为很奇怪，抛出了随机错误（例如，告诉表中的某个列虽然丢失了，或者告诉数据库已损坏）。

提示：我们仅对应用程序内的那些数据库具有READ访问权限。我们不向其中写入任何数据。

它仅发生在单个DB上，但这是应用程序中最复杂的一个。重新启动服务器将使其再次工作几分钟！

我们将完全相同的WAR文件部署到新旧平台进行测试。

已经分析

我们已经尝试了几件事，并做了一些分析步骤：

  1. 关闭防病毒解决方案（趋势科技服务器深度安全防护系统客户端）确实 没有帮助
  2. 将新服务器平台的服务器与另一组具有相同设置的服务器交换无济于事
  3. 将“损坏的”文件的SHA1哈希与原始文件进行比较 原来文件是相同的。
  4. 将“损坏的”数据库复制到另一个系统，并在那里进行测试 如预期的那样没有问题。
  5. 在数据库上运行完整性检查没有问题

  6. 检查有问题的服务器上的文件权限显示为否 问题

      

    ls -l /opt/apps/tomcat/i36/webapps/XXXX/database/XX/seg0/c8470.dat
      -rw-r--r-- 1 tomcat_i36 tomcat 16384 8月21日09:32 /opt/apps/tomcat/i36/webapps/XXXXX/database/XX/seg0/c8470.dat

         

    文件/opt/apps/tomcat/i36/webapps/XXXXX/database/XX/seg0/c8470.dat
      /opt/apps/tomcat/i36/webapps/XXXXX/database/XX/seg0/c8470.dat：数据

  7. 检查是否达到了任何Linux限制（例如，打开文件的限制）： 没找到

  8. 检查文件系统是否损坏：Ext3用于新旧版本 平台，找不到有关损坏文件的提示
  9. 将DERBY从10.11.1.1升级到10.12.1.1不能解决该问题。

服务器环境

旧环境（运行良好）

Linux: SUSE Linux Enterprise Server 11 SP4  (s390x)
Kernel: 3.0.101-91-default #1 SMP Mon Dec 12 13:06:13 UTC 2016 (544b9d1) s390x s390x s390x GNU/Linux
Filesystem: /dev/mapper/appsvg-lvapps on /opt/apps type ext3 (rw,acl,user_xattr)
Java: IBM 7.1-4.1
Tomcat: 7.0.70

新环境（无法正常工作）

Linux: SUSE Linux Enterprise Server for SAP Applications 12 SP3  (x86_64)
Kernel: 4.4.126-94.22-default #1 SMP Wed Apr 11 07:45:03 UTC 2018 (9649989) x86_64 x86_64 x86_64 GNU/Linux
Filesystem: /dev/mapper/appsvg-lvapps on /opt/apps type ext3 (rw,relatime,data=ordered)
Java: IBM 7.1-4.15
Tomcat: 7.0.85

我们的客户必须尽快迁移服务器平台，因此，如果有人可以协助我们检查和解决此问题，我们将感到非常高兴。

谢谢！

0 个答案:

没有答案
相关问题
最新问题