Je suis sur RedHat, Oracle 9.2.0.1.0 (et pas question pour l'instant
et sans BONNES raisons de passer de patches :-).
Voici comment j'obtient le message suivant : dans le fichier
alertMABASE.log :
Tue Sep 14 15:22:54 2004
Errors in file /oracle/product/9.2.0/rdbms/log/sevr_j000_26646.trc:
ORA-07445: exception trouvée : vidage coeur [qcdlgtd()+349] [SIGSEGV]
[Address not mapped to object] [0x0] [] []
J'ai une base DB1 qui contient des tables avec des snapshot log.
J'ai une base DB2 qui a un database link + des vues matérialisées
pointant sur DB1.
Quand j'arrête (shutdown immediate) DB1, Oracle produit 1 'core dump'
pour la base possédant les vues matérialisées (DB2), pour chaque table
en snapshot.
Quand je relance DB1, il m'est arrivé que tout refonctionne (mais
c'est bizzare c'est 'core dump'. Il m'arrive aussi (le cas
d'aujourd'hui), que mon database link soit supprimé (plus rien dans
SYS.DBA_DB_LINK). Une fois re-créé, tout reviens dans l'ordre.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
see
Bernard Segonnes wrote:
Je suis sur RedHat, Oracle 9.2.0.1.0 (et pas question pour l'instant et sans BONNES raisons de passer de patches :-).
Voici comment j'obtient le message suivant : dans le fichier alertMABASE.log :
Tue Sep 14 15:22:54 2004 Errors in file /oracle/product/9.2.0/rdbms/log/sevr_j000_26646.trc: ORA-07445: exception trouvée : vidage coeur [qcdlgtd()+349] [SIGSEGV] [Address not mapped to object] [0x0] [] []
Ce type d'erreur est assez générique. La probabilité de trouver une réponse dans ce forum est franchement réduite.
Si tu as un support auprès d'Oracle, je suppose que tu as ouvert un TAR. Et que la réponse a été : passer d'abord le dernier patchset et on en reparlera après.
C'est peut être pour cela d'ailleurs que tu poses la question dans le forum.
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Et ne réponds pas que tant que ça marche, je ne touche à rien car visiblement, cela ne marche pas aussi bien que cela. Tant que tu n'auras pas passé le dernier patchset, tu n'auras pas de support. Après c'est à toi de voir. Et avoir un support efficace peut constituer une BONNE raison de passer le patchset. Avec un peu de chance (probabilité assez élevé quand même), ton problème sera corrigé.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Bernard Segonnes <bsegonnes@free.fr> wrote:
Je suis sur RedHat, Oracle 9.2.0.1.0 (et pas question pour l'instant
et sans BONNES raisons de passer de patches :-).
Voici comment j'obtient le message suivant : dans le fichier
alertMABASE.log :
Tue Sep 14 15:22:54 2004
Errors in file /oracle/product/9.2.0/rdbms/log/sevr_j000_26646.trc:
ORA-07445: exception trouvée : vidage coeur [qcdlgtd()+349] [SIGSEGV]
[Address not mapped to object] [0x0] [] []
Ce type d'erreur est assez générique. La probabilité de trouver une
réponse dans ce forum est franchement réduite.
Si tu as un support auprès d'Oracle, je suppose que tu as ouvert un TAR.
Et que la réponse a été : passer d'abord le dernier patchset et on en
reparlera après.
C'est peut être pour cela d'ailleurs que tu poses la question dans le
forum.
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun*
patchset sur une version qui a apporté un lot quand même conséquent de
nouveauté ?
Et ne réponds pas que tant que ça marche, je ne touche à rien car
visiblement, cela ne marche pas aussi bien que cela. Tant que tu n'auras
pas passé le dernier patchset, tu n'auras pas de support. Après c'est à
toi de voir. Et avoir un support efficace peut constituer une BONNE
raison de passer le patchset. Avec un peu de chance (probabilité assez
élevé quand même), ton problème sera corrigé.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Je suis sur RedHat, Oracle 9.2.0.1.0 (et pas question pour l'instant et sans BONNES raisons de passer de patches :-).
Voici comment j'obtient le message suivant : dans le fichier alertMABASE.log :
Tue Sep 14 15:22:54 2004 Errors in file /oracle/product/9.2.0/rdbms/log/sevr_j000_26646.trc: ORA-07445: exception trouvée : vidage coeur [qcdlgtd()+349] [SIGSEGV] [Address not mapped to object] [0x0] [] []
Ce type d'erreur est assez générique. La probabilité de trouver une réponse dans ce forum est franchement réduite.
Si tu as un support auprès d'Oracle, je suppose que tu as ouvert un TAR. Et que la réponse a été : passer d'abord le dernier patchset et on en reparlera après.
C'est peut être pour cela d'ailleurs que tu poses la question dans le forum.
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Et ne réponds pas que tant que ça marche, je ne touche à rien car visiblement, cela ne marche pas aussi bien que cela. Tant que tu n'auras pas passé le dernier patchset, tu n'auras pas de support. Après c'est à toi de voir. Et avoir un support efficace peut constituer une BONNE raison de passer le patchset. Avec un peu de chance (probabilité assez élevé quand même), ton problème sera corrigé.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
bsegonnes
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun*
patchset sur une version qui a apporté un lot quand même conséquent de
nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII,
mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans
les cahiers des charges, contrats, que le dév est bien commencé, en
tests/prod. chez les clients, etc... c'est presque impossible de
modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait
une vraiment trés bonne raison pour convaincre les 'chefs' et clients
:-)
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand
on bosses dans une société.
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal
d'autres soft d'ailleur :-)
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
see
Bernard Segonnes wrote:
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* > patchset sur une version qui a apporté un lot quand même conséquent de > nouveauté ? Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ... Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends pas finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
Bernard Segonnes <bsegonnes@free.fr> wrote:
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun*
> patchset sur une version qui a apporté un lot quand même conséquent de
> nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII,
mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans
les cahiers des charges, contrats, que le dév est bien commencé, en
tests/prod. chez les clients, etc... c'est presque impossible de
modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait
une vraiment trés bonne raison pour convaincre les 'chefs' et clients
:-)
Je connais très bien le problème. Je maintiens que "avoir un support de
la part de Oracle" peut être une bonne raison.
Au minimum, quand Oracle sortira le patchset terminal, je pense que
c'est jouable. Pour un patchset intermédiaire, il est clair que c'est
très difficile. On voit bien que ce n'est pas le client qui discute
avec le support Oracle.
Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement
pas raisonnable mais je sais bien que ce n'est pas de ta faute.
Il existe un document (je peux te le retrouver si tu veux) de Oracle qui
précise sa politique par rapport aux patchsets :
- les patchsets n'introduisent aucune nouvelles fonctionnalités
- les patchsets font l'objets de tests de non-régressions
- 3 mois après sa sortie, Oracle demande que le dernier patchset soit
appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand
on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur
est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le
dernier patchset. Mieux vaut appliquer un patchset tranquillement que
dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal
d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends pas finition mais je trouve qu'Oracle
est un produit très stable. Il faut juste attendre un petit peu avant
d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les
patchsets (au moins les terminaux).
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* > patchset sur une version qui a apporté un lot quand même conséquent de > nouveauté ? Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ... Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends pas finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
see
Bernard Segonnes wrote:
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* > patchset sur une version qui a apporté un lot quand même conséquent de > nouveauté ? Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ... Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
Bernard Segonnes <bsegonnes@free.fr> wrote:
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun*
> patchset sur une version qui a apporté un lot quand même conséquent de
> nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII,
mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans
les cahiers des charges, contrats, que le dév est bien commencé, en
tests/prod. chez les clients, etc... c'est presque impossible de
modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait
une vraiment trés bonne raison pour convaincre les 'chefs' et clients
:-)
Je connais très bien le problème. Je maintiens que "avoir un support de
la part de Oracle" peut être une bonne raison.
Au minimum, quand Oracle sortira le patchset terminal, je pense que
c'est jouable. Pour un patchset intermédiaire, il est clair que c'est
très difficile. On voit bien que ce n'est pas le client qui discute
avec le support Oracle.
Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement
pas raisonnable mais je sais bien que ce n'est pas de ta faute.
Il existe un document (je peux te le retrouver si tu veux) de Oracle qui
précise sa politique par rapport aux patchsets :
- les patchsets n'introduisent aucune nouvelles fonctionnalités
- les patchsets font l'objets de tests de non-régressions
- 3 mois après sa sortie, Oracle demande que le dernier patchset soit
appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand
on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur
est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le
dernier patchset. Mieux vaut appliquer un patchset tranquillement que
dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal
d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle
est un produit très stable. Il faut juste attendre un petit peu avant
d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les
patchsets (au moins les terminaux).
> Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* > patchset sur une version qui a apporté un lot quand même conséquent de > nouveauté ? Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
> La 9.2 est encore en support avec correctifs, dommage de s'en priver ... Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
Lionel TETTAMANTI
Bruno Jargot a écrit :
Bernard Segonnes wrote:
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
Ne pas prendre en compte dans des grands projets la notion de maintenance applicative, est une aberration.
Dba de Production, en relation avec de nombreux services Etudes, nous appliquons dès que possible les derniers PATCHSET (après les avoir qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà rencontrés.
Por en revenir au problème initial, il y a http://metalink.oracle.com qui est fait pour ça (section bug databaqe search) et le support.
As-tu regardé de façon plus précise le fichier trace, il y a souvent des infos pertinentes.
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans le dictionnaire de données de la définition du database link !
CDLT
Bruno Jargot a écrit :
Bernard Segonnes <bsegonnes@free.fr> wrote:
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun*
patchset sur une version qui a apporté un lot quand même conséquent de
nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII,
mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans
les cahiers des charges, contrats, que le dév est bien commencé, en
tests/prod. chez les clients, etc... c'est presque impossible de
modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait
une vraiment trés bonne raison pour convaincre les 'chefs' et clients
:-)
Je connais très bien le problème. Je maintiens que "avoir un support de
la part de Oracle" peut être une bonne raison.
Au minimum, quand Oracle sortira le patchset terminal, je pense que
c'est jouable. Pour un patchset intermédiaire, il est clair que c'est
très difficile. On voit bien que ce n'est pas le client qui discute
avec le support Oracle.
Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement
pas raisonnable mais je sais bien que ce n'est pas de ta faute.
Il existe un document (je peux te le retrouver si tu veux) de Oracle qui
précise sa politique par rapport aux patchsets :
- les patchsets n'introduisent aucune nouvelles fonctionnalités
- les patchsets font l'objets de tests de non-régressions
- 3 mois après sa sortie, Oracle demande que le dernier patchset soit
appliqué en cas de nécessité de développer un correctif.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand
on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur
est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le
dernier patchset. Mieux vaut appliquer un patchset tranquillement que
dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal
d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle
est un produit très stable. Il faut juste attendre un petit peu avant
d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les
patchsets (au moins les terminaux).
Ne pas prendre en compte dans des grands projets la notion de
maintenance applicative, est une aberration.
Dba de Production, en relation avec de nombreux services Etudes, nous
appliquons dès que possible les derniers PATCHSET (après les avoir
qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà
rencontrés.
Por en revenir au problème initial, il y a http://metalink.oracle.com
qui est fait pour ça (section bug databaqe search) et le support.
As-tu regardé de façon plus précise le fichier trace, il y a souvent des
infos pertinentes.
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans
le dictionnaire de données de la définition du database link !
Très franchement, est-ce bien raisonnable de n'avoir passer *aucun* patchset sur une version qui a apporté un lot quand même conséquent de nouveauté ?
Je sais pas si tu as bossé sur des projets pour des clients en SSII, mais une fois qu'une version (OS, DB, divers lib/jar) est définie dans les cahiers des charges, contrats, que le dév est bien commencé, en tests/prod. chez les clients, etc... c'est presque impossible de modifier la config (nouveaux patches BD ou OS). Ou alors il faudrait une vraiment trés bonne raison pour convaincre les 'chefs' et clients :-)
Je connais très bien le problème. Je maintiens que "avoir un support de la part de Oracle" peut être une bonne raison. Au minimum, quand Oracle sortira le patchset terminal, je pense que c'est jouable. Pour un patchset intermédiaire, il est clair que c'est très difficile. On voit bien que ce n'est pas le client qui discute avec le support Oracle. Ceci dit, n'avoir appliqué strictement aucun patchset n'est franchement pas raisonnable mais je sais bien que ce n'est pas de ta faute. Il existe un document (je peux te le retrouver si tu veux) de Oracle qui précise sa politique par rapport aux patchsets : - les patchsets n'introduisent aucune nouvelles fonctionnalités - les patchsets font l'objets de tests de non-régressions - 3 mois après sa sortie, Oracle demande que le dernier patchset soit appliqué en cas de nécessité de développer un correctif.
La 9.2 est encore en support avec correctifs, dommage de s'en priver ...
Ouais si on fait du dev. pour sois-même à la maison. Pas facile quand on bosses dans une société.
C'est surtout pour la production qu'une bonne réactivité de l'éditeur est nécessaire. Et cette réactivité, tu ne l'auras qu'en appliquant le dernier patchset. Mieux vaut appliquer un patchset tranquillement que dans l'urgence ...
Oracle je trouve çà pas mal, mais manque de finition (tout pas mal d'autres soft d'ailleur :-)
Je ne sais pas ce que tu entends par finition mais je trouve qu'Oracle est un produit très stable. Il faut juste attendre un petit peu avant d'utiliser les nouvelles fonctionnalités et appliquer régulièrement les patchsets (au moins les terminaux).
Ne pas prendre en compte dans des grands projets la notion de maintenance applicative, est une aberration.
Dba de Production, en relation avec de nombreux services Etudes, nous appliquons dès que possible les derniers PATCHSET (après les avoir qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà rencontrés.
Por en revenir au problème initial, il y a http://metalink.oracle.com qui est fait pour ça (section bug databaqe search) et le support.
As-tu regardé de façon plus précise le fichier trace, il y a souvent des infos pertinentes.
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans le dictionnaire de données de la définition du database link !
CDLT
see
Lionel TETTAMANTI wrote:
Dba de Production, en relation avec de nombreux services Etudes, nous appliquons dès que possible les derniers PATCHSET (après les avoir qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà rencontrés.
Tout le problème est la phase de qualification en DEV/REC. Qui dit qualification dit budget et généralement, il n'y a pas de budget. Et personne ne veux prendre le risque de passer le patchset directement en production (ce qui ne me parait pas déraisonnable pour les bases non critiques). Quand en plus, l'informatique est gérée dans le cadre d'une infogérance avec des pénalités en cas d'indisponibilité, cela devient pratiquement impossible à moins de tomber sur un bug majeur qui rend inévitable l'application du patchset.
Lionel TETTAMANTI <goldorak@japan.co> wrote:
Dba de Production, en relation avec de nombreux services Etudes, nous
appliquons dès que possible les derniers PATCHSET (après les avoir
qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà
rencontrés.
Tout le problème est la phase de qualification en DEV/REC. Qui dit
qualification dit budget et généralement, il n'y a pas de budget. Et
personne ne veux prendre le risque de passer le patchset directement en
production (ce qui ne me parait pas déraisonnable pour les bases non
critiques).
Quand en plus, l'informatique est gérée dans le cadre d'une infogérance
avec des pénalités en cas d'indisponibilité, cela devient pratiquement
impossible à moins de tomber sur un bug majeur qui rend inévitable
l'application du patchset.
Dba de Production, en relation avec de nombreux services Etudes, nous appliquons dès que possible les derniers PATCHSET (après les avoir qualifiés en DEV/REC) de cette façon nous limitons les problèmes déjà rencontrés.
Tout le problème est la phase de qualification en DEV/REC. Qui dit qualification dit budget et généralement, il n'y a pas de budget. Et personne ne veux prendre le risque de passer le patchset directement en production (ce qui ne me parait pas déraisonnable pour les bases non critiques). Quand en plus, l'informatique est gérée dans le cadre d'une infogérance avec des pénalités en cas d'indisponibilité, cela devient pratiquement impossible à moins de tomber sur un bug majeur qui rend inévitable l'application du patchset.
bsegonnes
Por en revenir au problème initial, il y a http://metalink.oracle.com qui est fait pour ça (section bug databaqe search) et le support.
De toute façon, on l'a le support Oracle, on est 2 personnes de ma boite a avoir mis notre pb par tél. et directement sur Metalink. Donc on a 2 contacts chez Oracles, avec 2 pistes assez différentes :-) ! Par contre, pas encore de solution. Serait-on les seul/premiers au monde à ce pb ??
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans le dictionnaire de données de la définition du database link !
Merci c'est une piste, le pb avec le dictionnaire de donnée. Je vois avec Metalink
Por en revenir au problème initial, il y a http://metalink.oracle.com
qui est fait pour ça (section bug databaqe search) et le support.
De toute façon, on l'a le support Oracle, on est 2 personnes de ma
boite a avoir mis notre pb par tél. et directement sur Metalink. Donc
on a 2 contacts chez Oracles, avec 2 pistes assez différentes :-) !
Par contre, pas encore de solution. Serait-on les seul/premiers au
monde à ce pb ??
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans
le dictionnaire de données de la définition du database link !
Merci c'est une piste, le pb avec le dictionnaire de donnée. Je vois
avec Metalink
Por en revenir au problème initial, il y a http://metalink.oracle.com qui est fait pour ça (section bug databaqe search) et le support.
De toute façon, on l'a le support Oracle, on est 2 personnes de ma boite a avoir mis notre pb par tél. et directement sur Metalink. Donc on a 2 contacts chez Oracles, avec 2 pistes assez différentes :-) ! Par contre, pas encore de solution. Serait-on les seul/premiers au monde à ce pb ??
Il y a cependant un point qui me surprend beaucoup, c'est la perte dans le dictionnaire de données de la définition du database link !
Merci c'est une piste, le pb avec le dictionnaire de donnée. Je vois avec Metalink
bsegonnes
Cà avait l'air d'être le 'dual' qui provoquait le core dump...
Aprés l'avoir enlevé de mon materialized view, on n'a plus le core dump, mais çà va pas mieux pour autant. Le pb de refraichissment à l'air de venir de type de refresh (fast, force, with rowid,...)
FAST : marche pas car notre MV est 'complexe'. Je vois pas pourquoi, mais c'est comme çà !
FORCE, WITH ROWID : refraichis bien les snapshot, MAIS si la base distante est pas en ligne, les lignes des snapshots sont vidées !!! C'est pas ce que l'on désire :-)
Idées ?
Cà avait l'air d'être le 'dual' qui provoquait le core dump...
Aprés l'avoir enlevé de mon materialized view, on n'a plus le core
dump, mais çà va pas mieux pour autant. Le pb de refraichissment à
l'air de venir de type de refresh (fast, force, with rowid,...)
FAST : marche pas car notre MV est 'complexe'. Je vois pas pourquoi,
mais c'est comme çà !
FORCE, WITH ROWID : refraichis bien les snapshot, MAIS si la base
distante est pas en ligne, les lignes des snapshots sont vidées !!!
C'est pas ce que l'on désire :-)
Cà avait l'air d'être le 'dual' qui provoquait le core dump...
Aprés l'avoir enlevé de mon materialized view, on n'a plus le core dump, mais çà va pas mieux pour autant. Le pb de refraichissment à l'air de venir de type de refresh (fast, force, with rowid,...)
FAST : marche pas car notre MV est 'complexe'. Je vois pas pourquoi, mais c'est comme çà !
FORCE, WITH ROWID : refraichis bien les snapshot, MAIS si la base distante est pas en ligne, les lignes des snapshots sont vidées !!! C'est pas ce que l'on désire :-)
Idées ?
Dark Angel
Il me semble avoir lu ca dans oracle magazine,
faut s'abonner, c'est gratuit, et tu as un support
Il me semble avoir lu ca dans oracle magazine,
faut s'abonner, c'est gratuit, et tu as un support
