Exception ORA-08103: l'objet n'existe plus sur l'utilisation de setfetchsize de Hibernate

Je suis de l'utilisation d'Hibernate. J'ai besoin de récupérer environ 1000000 dossiers et il fera exception délai. Donc je suis en utilisant setfetchsize de 6000 dossiers, de sorte qu'il distribuera l'opération dans de multiples transactions chacun de 6000 dossiers.

Il prendra autour de 21 heures à chercher tous les.

Mais en attendant, la récupération des documents si quelqu'un supprime l'un de l'enregistrement qui a été récupéré puis-je obtenir ORA-08103: object no longer exists.

Maintenant, je veux ignorer que l'objet qui est supprimé lors de la récupération. Comment puis-je faire cela?

Ne connais pas le contexte de ce que vous essayez de faire, mais pourquoi devez-vous utiliser hibernate, et pas directement de sql ou pl/sql appels. Serait beaucoup plus rapide.
Je ne peux pas remplacer Hibernate car il vous en coûtera plus de temps de la consommation de projet.Mon problème est que sur l'exécution de executeQuery oracle va jeter ORA-08103: l'objet n'existe plus exception parce que quelqu'un a supprimé un dossier dont j'ai été chercher de l'aide executeQuery. Maintenant je ne peux pas empêcher quiconque de supprimer une ligne du temps quand je suis aller chercher des dossiers, donc je veux une technique qui va provoquer oracle de ne pas jeter l'exception de l'enregistrement supprimé au lieu de cela Il doit ignorer que d'enregistrer et de procéder à la prochaine.
Pourquoi êtes-vous récupérer un million de lignes dans l'application? Il me semble qu'il y a possibilité de faire un traitement supplémentaire dans la base de données, d'économiser beaucoup de temps.

OriginalL'auteur Barney | 2013-09-11

  1. 15

    Plus probable qu'un curseur est ouvert sur une table temporaire globale(GTT), qui avait été créé avec ON COMMIT DELETE ROWS option. Et la cause de la ORA-08103: object no longer exists erreur est commit déclaration qui a suivi juste après la delete déclaration. Voici un exemple simple:

     SQL> declare
  2    type t_recs is table of number;
  3    l_cur sys_refcursor;    -- our cursor
  4    l_rec t_recs; 
  5  
  6  begin
  7  
  8    -- populating a global temporary table GTT1 with sample data  
  9    insert into GTT1(col)
 10      select level
 11        from dual
 12     connect by level <= 1000;
 13  
 14   open l_cur         -- open a cursor based on data from GTT1
 15    for select col
 16          from GTT1;
 17  
 18    -- here goes delete statement
 19    -- and
 20    commit;  <-- cause of the error. After committing  all data from GTT1 will be
 21              -- deleted and when we try to fetch from the cursor
 22    loop      -- we'll face the ORA-08103 error
 23      fetch l_cur    -- attempt to fetch data which are long gone.
 24       bulk collect into l_rec;
 25      exit when l_cur%notfound;
 26    end loop;
 27  
 28  end;
 29  /


ORA-08103: object no longer exists
ORA-06512: at line 24

    Des loisirs de la table temporaire globale avec on commit preserve rows clause lui permettront de récupérer des données à partir d'un curseur qui est basé sur la table sans avoir peur de faire face à ORA-08103: erreur.

    Pensez-vous qu'il peut être une autre explication? J'ai commencé à avoir cette erreur avec les grands inserts (juste un simple insert.. select) à partir d'une vue dans une table sur laquelle supprime pas se produire. C'est possible qu'un autre processus est en train d'essayer de tronquer la table en dessous, mais la "première" table doit être verrouillé, ce qui permettrait d'éviter que cela se produise.
    si vous êtes à la troncation d'une table tandis qu'un insert select instruction en cours, oui, vous obtiendrez la même erreur simplement parce que select déclaration est un curseur et truncate déclaration, comme c'est une instruction DDL, cause double - validation avant de les tronquer et puis après.
    Ah, oui, bien sûr; merci Nicolas. Je vais avoir à traquer que rogue processus, alors...

    OriginalL'auteur

  2. 0

    Après avoir passé une semaine enfin j'ai résolu le Problème:

    Solution: le Plus probable qu'un curseur est ouvert sur une table temporaire globale(GTT), qui avait été créé avec SUR les COMMETTRE SUPPRIMER des LIGNES d'option. Et la cause de l'ORA-08103: l'objet n'existe plus d'erreur est s'engager déclaration qui a suivi juste après l'instruction delete. DBA équipe n'a pas d'accord pour changer la GTT, comme lors de la validation de préserver les lignes donc, finalement, j'ai ajouté le code de base en Java de la Couche de Service[la mise en Œuvre de la collection Printemps - Transaction Programmatique]

    package com.test;
import java.util.List;
import javax.sql.DataSource;
import org.springframework.dao.DataAccessException;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionDefinition;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionDefinition;
public class StudentJDBCTemplate implements StudentDAO {
private DataSource dataSource;
private JdbcTemplate jdbcTemplateObject;
private PlatformTransactionManager transactionManager;
public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;
this.jdbcTemplateObject = new JdbcTemplate(dataSource);
}
public void setTransactionManager(PlatformTransactionManager transactionManager) {
this.transactionManager = transactionManager;
}
public void create(String name, Integer age, Integer marks, Integer year){
TransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus status = transactionManager.getTransaction(def);
try {
String SQL1 = "insert into Student (name, age) values (?, ?)";
jdbcTemplateObject.update( SQL1, name, age);
// Get the latest student id to be used in Marks table
String SQL2 = "select max(id) from Student";
int sid = jdbcTemplateObject.queryForInt( SQL2 );
String SQL3 = "insert into Marks(sid, marks, year) " + "values (?, ?, ?)";
jdbcTemplateObject.update( SQL3, sid, marks, year);
System.out.println("Created Name = " + name + ", Age = " + age);
transactionManager.commit(status);
} 
catch (DataAccessException e) {
System.out.println("Error in creating record, rolling back");
transactionManager.rollback(status);
throw e;
}
return;
}
public List<StudentMarks> listStudents() {
String SQL = "select * from Student, Marks where Student.id=Marks.sid";
List <StudentMarks> studentMarks = jdbcTemplateObject.query(SQL, 
new StudentMarksMapper());
return studentMarks;
}
}

    OriginalL'auteur