Discussion :

[shanod]

Bonjour à tous !

Contexte

J'ai actuellement un mini projet de réorganisation de tables Oracle dans un environnement SAP.
Nous devons reconstruire fréquemment les index de certaines de nos tables et nous avons décidé de planifier cela toutes les semaines via un ordonnanceur.
Cet ordonnanceur ne comprend que le shell et le script doit être dynamique pour s'adapter à toutes les tables.

Mis en place

J'ai donc récupéré mes commandes Oracle de Rebuild Index que j'ai collé dans un KSH.
A présent, je dois connaitre les noms des index que contiennent chacune de mes tables. Pas de soucis, une requête SQL fait sa très bien.

Question

Le résultat de ma requête me donne donc NOM_TABLE~1 NOM_TABLE~2 NOM_TABLE~3 NOM_TABLE~4 NOM_TABLE~5
Est ce qu'une commande SQL me permet de mettre chacun de mes noms d'index dans une variable ?

Etant dans un environnement KSH, je pourrai exporter tout le résultat de la requête dans une seule variable et ensuite travailler avec des sous-chaînes pour extraire chacun de mes index mais je n'ai pas envie de monter une usine à gaz étant donné mes connaissances limitées en KSH...

Merci par avance pour vos propositions

[Rei Ichido]

Bonjour à tous !

Contexte

J'ai actuellement un mini projet de réorganisation de tables Oracle dans un environnement SAP.
Nous devons reconstruire fréquemment les index de certaines de nos tables et nous avons décidé de planifier cela toutes les semaines via un ordonnanceur.

Il y a une raison à ce rebuild systématique, plutôt qu'à un bête coalesce ?

Question

Le résultat de ma requête me donne donc NOM_TABLE~1 NOM_TABLE~2 NOM_TABLE~3 NOM_TABLE~4 NOM_TABLE~5
Est ce qu'une commande SQL me permet de mettre chacun de mes noms d'index dans une variable ?

De toute façon, tes "variables" seront des variables shell, donc le SQL n'a pas grand chose à voir ?
Par contre sous Oracle, tu pourrais (devrais ?) gérer tout ceci en PL/SQL avec une procédure stockée (ton ksh se limitant à lancer la procédure). Là, effectivement, tu peux stocker tes informations facilement, et faire tout ce que tu veux dans ta base avec.

[pacmann]

Salut,

Effectivement en PL, c'est mieux comme dit Rei.

La clef de ton problème : EXECUTE IMMEDIATE + TaRequeteSousChaineDeCaracteres.

Tu peux lancer ça à l'intérieur de ton curseur qui parcourt dba_indexes...

[shanod]

Il y a une raison à ce rebuild systématique, plutôt qu'à un bête coalesce ?

Je ne connais pas la commande coalesce, mais d'après ce que j'en lis il s'agit d'une optimisation de l'espace libre, et cela doit prendre pas mal de temps...

Alors que nous n'avons qu'une seule table qui est très sollicitée et nécessite une réorg des index et des statistiques régulièrement pour garder des temps de réponse satisfaisant.

Ceci dit, c'est exactement le genre de réponse que j'attends Rei
N'étant pas du tout DBA, je me dis qu'il existe peut être une commande Oracle qui me permettrai d'éviter d'avoir à retravailler le résultat de ma requête.

[Rei Ichido]

De ce que j'ai pu voir et lire, dans le cas général les rebuilds systématiques d'index à intervalle régulier ne sont pas nécessaires. Je parle bien ici d'un rebuild lié au temps, et non à des imports massifs - mais en l'occurrence, dans ce ce cas là, c'est parce qu'on désactive l'index dans un premier temps.

Je te suggère de tester sur un environnement iso-prod (si tu as ça sous la main) ce qui se passe si tu ne rebuild pas, mais fais simplement du coalesce + calcul stats ?

Dernier point, au sujet du temps : la consommation d'un coalesce est moindre vis à vis d'un rebuild.