Haute disponibilité lors des installations PL/SQL

[Wurlitzer]

Bonjour,

Quand on me parle "Haute disponibilité". Je pense RAC, etc. C'est parfait en cas de crash hardware. Mais là, on vient de me poser une question et j'avoue ne pas savoir comment m'y prendre.

Le but est de supprimer les interruptions de service lors des installations de patchs. Pas ceux de binaires Oracle mais ceux de l'application installé dans la base.

Quand on modifies une table ou un bout de code cela invalide d'autre procédure, package et trigger en chaîne et l'appli devient inutilisable.

Avez vous des idées ? Mis à part d'utiliser un maximum de package pour limiter la propagation en chaine de Invalidation.

Merci,

PS Je suis en 8.1.7.4 mais je suis preneur de solution même dans les version supérieur

[pifor]

Quand on modifies une table ou un bout de code cela invalide d'autre procédure, package et trigger en chaîne et l'appli devient inutilisable.

Ca dépend. En général, il y a problème si on utilise un package qui utilise une variable de session; dans ce cas je crois qu'on a l'erreur ORA-4068 et il devrait suffire de relancer l'instruction en cours ou au plus la transaction courante. L'idéal serait de modifier le client pour que cette erreur soit reconnue et traitée de façon transparente ... Avez-vous d'autre cas d'erreur sans variable de session ?

Le mécanisme d'invalidation des objets PL/SQL est automatique et récursif.
Le mécanisme de recompilation d'un objet invalide est aussi automatique lors de l'exécution d'un objet PL/SQL. Il me semble impossible de le contourner à moins d'avoir uniquement du SQL dynamique

[Wurlitzer]

Le probleme exacte que j'ai c'est modification d'une table qui entraine plusieurs package INVALID. Et comme l'appplication est ONLINE les utilisateurs essayent d'utiliser ces packages ce qui lance des recompilations automatiques dans tout les sens et qui finalement se lockent les une et les autres.

Un autre problème c'est qu'utilisateur utilise un package et qu'il est donc locké et donc que je ne peux pas le recompiler

Merci

[pifor]

Dans ce cas, il faut sans doute d'arrêter l'application quelque minutes, le temps d'exécuter le DDL et de forcer la recompilation de tous les objets du schéma.
Ou essayer d'utiliser le package DBMS_REDEFINITION: http://download-uk.oracle.com/docs/c...bles.htm#12458

[LeoAnderson]

DBMS_REDEFINITION ne permet de redéfinir le schéma, pas les PL/SQL !

Si la table change, le PL/SQL dépendant sera invalidé mais revalidé au 1er appel...

Sinon, je ne vois pas en quoi ça pourrait aider ...

[remi4444]

Il y à 2 niveaux de haute-dispo, la haute disponibilité en lecture et la haute disponnibilité en modifications.

Evidemment, le mode lecture-seule doit etre plus simple à gérer.

Premièrement, j'avoue ma totale ignorance du RAC donc je ne sais pas si cette architecture résoudrait plus facilement ton problème....

Je pense qu'il faut utiliser 2 bases et jouer sur le switch de l'une à l'autre. Ensuite pour l'accès, il faut utiliser le mode FAILOVER de net8:

http://download-west.oracle.com/docs...cfg.htm#473298

Prenons l'hypothèse que tu ne veuilles assurer la haute dispo qu'en lecture:

Voici un exemple d'une architecture haute dispo que j'ai déja mis en place:

- Une base A sur une machine A avec 2 listeners: un listener public et un privé
- Une base B standby de la base A avec 2 listeners: un listener public etteint et une listener privé. La communication entre les 2 bases se fait par les listeners privés.

Les tnsnames.ora des clients oracle sont paramétrés en mode failover avec 2 lignes pointant chacune sur le listener public des 2 machines. Il faut paramètrer un nombre conséquent de RETRIES dans ton tnsnames public pour que les connexions puissent rester "en l'air" un petit moment.

Scénario de passage de patch:

- Switch log sur la base A pour répercuter les dernieres modifs sur la standby B
- ouverture de la base B en mode "read-only"
- stop du listener public de la machine A
- start du listener public de la machine B
- Kill des sessions utilisateurs de la machine A, c'est là que c'est fort, parce qu'elles vont se connecter de suite sur la base B de manière totalement transparante pour le client. Pour pas s'embêter, on peu faire un arret/relance de la base A.
- passage des patchs sur la base A.
- tests de la nouvelle version en passant par le listener privé de A
- une fois validé, start du listener public de A
- stop du listener public de B
- Fermeture de B (les clients re-basculeront sur A)
- relance de B en mode standby (les modifs vont alors se repercuter)


Pour une haute dispo en mode modification, je n'ai jamais mis ça en place mais il faut surement jouer subtil pour réussir à basculer les client sur une base active (activation de la standby avec perte de lien sur la primaire) passer le patch sur la base primaire, réussir à récupérer les données modifiées de la base B (grace à des snatpshot log par ex...) avant de re-basculer les clients sur la base primaire.

Si une suspension de service de quelques petites minutes est tolérable, le plus simple est toujours d'utiliser le mode failover de net8 mais avec une seule base A:
- stopper le listener public de A
- killer les sessions des clients, chaque action de client sera alors suspendue.
- passer le patch sur la base A en passant par le listener privé
- rallumer le listener public. Les clients se reconnecteront tout seuls et reprendront leurs activités là ou elles on été suspendues.

[Wurlitzer]

Merci pour cette longue reponse. Je suis malheureusement dans le mode avec modification donc dans le cas compliqué.

Je vais étudier tout cela ! !

[remi4444]

Envoyé par Wurlitzer

Merci pour cette longue reponse. Je suis malheureusement dans le mode avec modification donc dans le cas compliqué.

Je vais étudier tout cela ! !

En y repensant, je pense que ça va etre difficile de trouver une solution qui fonctionne pour n'importe quel type de mise à jour, imagine que tu eclates une table en 2 par exemple, il y aura forcément un moment ou il va faloir récupérer des données modifiées pendant le passage du patch par une requête spécifique...

Si le patch est bien fait, je pense qu'il peut se faire sans arret de prod mais il faut qu'il reussisse à compiler dans le bon ordre les procédures en veillant à chaque fois à la compatibilité de la nouvelle proc avec les anciennes quite à passer par des compilations intermédiaire de procédures temporaires pour ne jamais perdre la cohérence.... mais c'est un gros boulot au niveau du dev lui même...

[Wurlitzer]

Oui je pense comme toi que cela doit être possible avec un gros boulot au niveau des dev et de l'intégration pour tester les scénarios de passage de patch.

Et la je ne crois pas qu'on soit prêt a cet effort...

On en revient au beurre l'argent du beurre et surtout sourire de la crémières

[remi4444]

Du moment tu as le sourire de la crêmière à la fin, c'est le seul point essentiel à mon avis...