Не найдено подходящего драйвера для подключения к базе данных Oracle

у меня есть небольшое Java-приложение, которое выполняется каждый день и проверяет данные в базе данных с помощью Cronj Schedular, и все работает нормально, но недавно я заметил, что он терпит неудачу из-за

java.sql.SQLException: No suitable driver found for jdbc:oracle:thin:@160.110.xx.xxx:1521/test

в то же время, когда я запускаю свой тестовый код для проверки подключения к базе данных, который отлично работает без исключения. Я не могу понять. Хотя, было только небольшое изменение кода, но это не было связано с базой данных или подключением к базе данных. Кто-нибудь, помогите я в этом ?

dbconf.java

public class dbconf {

    private Connection connect;
    private String connstr;

    public Connection getConnection() throws SQLException {
        connstr = "jdbc:oracle:thin:@160.110.xx.xxx:1521/test";

        try {
                String uname = "scott";
                String pass = "tiger";
                Class.forName("oracle.jdbc.OracleDriver").newInstance();
                connect = DriverManager.getConnection(connstr, uname, pass);

        } catch (Exception e) {
            System.out.println(e.toString());
        }

            return connect;
    }
}

я использую ojdbc6.Джар и Oracle11g

Edited-файл журнала приложений

Wed Jul 01 09:25:17 IST 2015:------- Initializing -------------------
Wed Jul 01 09:25:17 IST 2015:------- Scheduling Jobs ----------------
Wed Jul 01 09:25:17 IST 2015:------- Job Started Running ----------------
Thu Jul 02 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
java.sql.SQLException: No suitable driver found for jdbc:oracle:thin:@160.xxx.67.xxx:1521/test
Sat Jul 04 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
Sun Jul 05 06:00:00 IST 2015 : Job Executed..!! Bschedularv2.2
java.sql.SQLException: No suitable driver found for jdbc:oracle:thin:@160.xxx.67.xxx:1521/test

Итак, вы видите, он потерпел неудачу 3 и 6 июля. Но между ними все было в порядке.

==обновление 1==

кажется, никто не читает мой вопрос должным образом, я четко упомянул, что это когда-нибудь все будет хорошо, но когда-нибудь это закончится неудачей. Если это была проблема classpath, то она не должна была работать в любой день.

===обновление 2===

многие из приведенных ниже ответов были бессмысленными, но немногие имели какой-то логический взгляд. Я использовал printStracktrace и попытался отладить каждую точку, и, наконец, я получил некоторую подсказку. 3 дней назад я развернул новую версию приложения на том же сервере (включая printStackTrace и SysOut), первые 2 дня он работал нормально, сегодня это не удалось следующая ошибка.

INFO: Illegal access: this web application instance has been stopped already.  Could not load com.schedular.job.BirthdayJob.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1600)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
    at org.quartz.simpl.LoadingLoaderClassLoadHelper.loadClass(LoadingLoaderClassLoadHelper.java:59)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:99)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:138)
    at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.java:852)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2816)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.execute(JobStoreSupport.java:2759)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.execute(JobStoreSupport.java:2757)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3787)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTriggers(JobStoreSupport.java:2756)
    at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:272)

Jul 13, 2015 6:00:00 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  Could not load com.schedular.job.BirthdayJob.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1600)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
    at org.quartz.simpl.LoadingLoaderClassLoadHelper.loadClass(LoadingLoaderClassLoadHelper.java:59)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:99)
    at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:138)
    at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.java:852)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob(JobStoreSupport.java:1385)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggerFired(JobStoreSupport.java:2964)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.execute(JobStoreSupport.java:2908)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.execute(JobStoreSupport.java:2901)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3787)
    at org.quartz.impl.jdbcjobstore.JobStoreSupport.triggersFired(JobStoreSupport.java:2900)
    at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:336)

11 ответов


правильный формат для вашего URL JDBC-это не то, что вы написали:

connstr = "jdbc:oracle:thin:@160.110.ХХ.ХХХ:1521/тест";

, а как

connstr = "jdbc:oracle:thin:@//160.110.ХХ.ХХХ:1521/тест";

или

connstr = "jdbc:oracle:thin:@160.110.ХХ.ХХХ:1521:тест";

в зависимости от того, является ли "тест" службой или SID.

Бревно фрагмент, который вы показали, не показывает, что метод getConnection работал на 4-м! Это только показало, что ошибки не было. Возможно, это просто означало, что метод никогда не вызывался (поэтому попытка подключения не предпринималась).


Не уверен, если это помогает, Но это код, который я должен сделать то же самое,

    try { 
        Class.forName("oracle.jdbc.driver.OracleDriver"); 
    } catch (ClassNotFoundException e) { 
        System.out.println("Could not load the driver"); 
    } 

    Connection conn = DriverManager.getConnection                                     ("jdbc:oracle:thin:@ten10:1521:acdb", user, pass); 

Так, не совсем тот же класс.forName, но та же форма для протокола.

класс для имени необходим, он гарантирует, что загрузчик классов загрузил драйвер Oracle jdbc.

что может произойти, это некоторая проблема подключения на машине, где выполняется код, так что расположение, содержащее фактический ojdbc6.jar (как указано на пути к классам) не всегда доступен (если он не находится на локальном диске ?).


кажется, " ojdbc6.jar " не находится в пути к классам вашего сервера приложений.


когда он говорит, что не может найти класс, он не может найти класс.

по моему опыту, такого рода проблемы, которые иногда работают,а иногда не связаны с потоком. Мое предположение ClassLoader загружает ваш класс async, поэтому вызов соединения сразу после загрузки может быть проблемой. вы пытались загрузить класс oracle в статическую часть? что-то вроде:

public class dbconf {

static {
  Class.forName("oracle.jdbc.OracleDriver");
}

public Connection getConnection() throws SQLException {
    String connstr = "jdbc:oracle:thin:@160.110.xx.xxx:1521/test";
    try {
        String uname = "scott";
        String pass = "tiger";
        return DriverManager.getConnection(connstr, uname, pass);
    } catch (Exception e) {
        System.out.println(e.toString());
    }
}
}

еще одна проблема: ваш код компилируется каждый день(путем непрерывной доставки или ...)?


похоже проблема с вашим банку попробовать заменить ojdbc14.jar и добавьте его в Class-path, если вы используете Eclipse, выполните следующие действия:- Eclipse -- > (выберите проект)перейдите в свойства --> путь сборки Java--> выберите Добавить Jar или добавить внешний Jar.


Если возможно, просмотрите println для DriverManager.метод getconnection () метод. Вы можете получить нулевой объект соединения из БД без каких-либо исключений во время сбоев.

SQLException reason = null;
for(DriverInfo aDriver : registeredDrivers) {
    if(isDriverAllowed(aDriver.driver, callerCL)) {
        try {
            println("    trying " + aDriver.driver.getClass().getName());
            Connection con = aDriver.driver.connect(url, info);
            if (con != null) {
                println("getConnection returning " + aDriver.driver.getClass().getName());
                return (con);
            }
        } catch (SQLException ex) {
            if (reason == null) {
                reason = ex;
            }
        }

    } else {
        println("    skipping: " + aDriver.getClass().getName());
    }

}
if (reason != null)    {
    println("getConnection failed: " + reason);
    throw reason;
}
println("getConnection: no suitable driver found for "+ url);
throw new SQLException("No suitable driver found for "+ url, "08001");

возможное решение: перейдите в Средство просмотра событий - > архивы Windows и удалите события приложения и системные события.(Не удаляйте события безопасности!).После этого перезагрузите компьютер, и вы будете в порядке.


Я не знаком с" schedular", но ваше последнее обновление предполагает, что у вас есть потоки, которые не были чисто остановлены из предыдущего undeploy/redeploy. Есть javaspecialists бюллетень о том, как отключить потоки чисто.

интересно, может быть, ваш код выключения сервлета отменяет регистрацию драйвера базы данных? Из вашего stacktrace похоже, что вы работаете в Tomcat. Даже если ваш код не регистрирует драйвер напрямую, Я считаю, что Tomcat 7 и выше отменит регистрацию драйверов в рамках обнаружения/смягчения утечки памяти Tomcat.

Это может объяснить, почему водитель иногда присутствует, а иногда нет.


Не сохраняйте имя драйвера статическим способом. Используйте JDBC + Java API, чтобы получить имя класса драйвера следующим образом:

public class dbconf {

    private Connection connect;
    private String connstr;

    public Connection getConnection() throws SQLException {
        connstr = "jdbc:oracle:thin:@160.110.xx.xxx:1521/test";

        try {
                String uname = "scott";
                String pass = "tiger";
                Class.forName(OracleDriver.class.getClass().getName().toString()).newInstance();
                connect = DriverManager.getConnection(connstr, uname, pass);

        } catch (Exception e) {
            System.out.println(e.toString());
        }

            return connect;
    }
}

лучше, если вы сделали опечатку или и вы можете проверить, является ли ojdbc6.jar установлен в пути сборки в хорошем смысле..

Надеюсь, эта информация поможет...


Как кто-то подошел ко мне для решения этого вопроса. Я отправляю его сейчас.

  1. Я не развернул приложение, у которого была эта проблема, и очистил все связанные файлы с сервера.
  2. затем я перезапустил сервер tomcat. Таким образом, он будет очищать все временные файлы и кэш.
  3. затем я развернул то же приложение, и он начал работать без каких-либо проблем.

ошибка означает, что драйвер, который вы используете, не принимает URL-адрес подключения. Похоже, что Ваш URL использует синтаксис MySQL (имя БД, разделенное '/'). Попробуйте использовать конкретное определение Oracle: jdbc:oracle:thin:@160.110 - ... xx.xxx: 1521: test