Augmentation de la taille d'un tablespace

[atporfi]

Je travaille sur une base de donnée 9.2.0.3 et en tantque dba(débutant) je dois vérifier la taille des tablespace quotidiennement en utilisant une requête me donnant comme résultat l'espace libre de chaque tablespace ,alors si je constate que pour un tablespace donné ,lui restant que 10% par exemple je dois augmenter sa taille (datafiles),ce que je veux savoir c :
Y-a-t-il une regle de calcul bien précise ?
Dois je augmenter la taille des datafiles ?si oui à base de quoi ?
Est ce qu'il ya une limite de taille pour un tablespace (en Go)? actulellement j'ai un tablespace qui atteint les 7Go

Merci pour votre aide et collaboration !

[orafrance]

Et pourquoi pas utiliser l'AUTOEXTENT qui fait tout ce travail pour toi ?

[lmartin]

Quand tu dis je dois, c'est ton chef qui t'as demandé ça ou bien est-ce de ta propre initiative ?

Si tu as libre arbitre, il vaut mieux que tu définisse une taille maximale par datafile (MAXSIZE) et que tu passes en AUTOEXTEND ON.
Le seul intérêt de resizer chque jour serait de gagner sur les temps d'insertions, le temps qu'Oracle prend à agrandir ses fichiers.

Sinon la règle d'ajout c'est un multiple de ta taille d'extent, si t'es en extension "unifom size".

[philcero]

Personnellement, je déconseille fortement l'utilisation de l'AUTOEXTEND car c'est un mécanisme dangereux quand on travaille sur des machines mutualisées et/ou à base de baies. La moindre application qui part en vrille et c'est invisible.

D'un point de vue strictement professionnel, la vie des occupations disques est à la charge du DBA et ce pour une simple et bonne raison, il est de sa responsabilité de prévoir l'avenir. Autrement dit de pouvoir capitaliser sur le passé et surtout de parfaitement connaître les us et coutumes des espaces sous sa responsabilité afin de prévoir les besoins notamment en espaces disques. Dans un groupe entre le déclenchement de l'analyse et l'arrivée du matériel il se passe plusieurs semaines et si une base explose pour cause de besoin d'espace disque non prévu, c'est la tête du DBA qui tombe et c'est normal.

D'un point de vue technique maintenant, il y a deux choses à savoir.

- La première quelles sont les habitudes des objets du tablespace analysé . Des archives annualisées même à 99% ne grandiront pas plus.

- La deuxième est généralement plus une notion d'espace libre que de ratio. Il faut que tes espaces libres proposent au moins un segment contigu de la taille du plus grand EXTENT de tes objets.

Va faire un tour du côté ses vues DBA_TABLES & DBA_INDEXES (Pour récupérer ton NEXT_EXTENT) et du côté de la vue DBA_FREE_SPACES (Pour récupérer BYTES). Le tout filtré sur ton nom de TABLESPACE devrait être pas mal.

Je ne te donne pas la soluce, je ne fais que te mettre suer la voie, pour une simple et bonne raison : Pour être DBA il faut apprendre à réfléchir

[olivanto]

Envoyé par philcero

Personnellement, je déconseille fortement l'utilisation de l'AUTOEXTEND car c'est un mécanisme dangereux quand on travaille sur des machines mutualisées et/ou à base de baies. La moindre application qui part en vrille et c'est invisible.

Faut vraiment avoir du temps à perdre pour vérifier les tablespaces en temps réel ! De toute façon, une appli. peut très bien partir en vrille, comme tu le dis, avant que tu n'ai le temps de réagir...

Franchement, le plus simple en encore l'Autoextend, et tu bloques la taille maximale du tablspace....

[philcero]

Tout dépends de ce que tu gère. Quand tu gère des bases pharmaceutiques une appli qui part en vrille doit être maîtrisée le plus vite possible. Dans ce cas précis, un check des bases automatisé toutes les 10 minutes permet d'analyser les comportements et de traiter les problèmes en casi temps réel.

Dans le cadre d'une base non sensible, un check journalier peut suffire. Dans tous les cas l'historisation des utilisations des espaces disques et entièrement à la charge du DBA et c'est pas en faisant de l'AUTOEXTEND qu'on y arrive pour la simple et bonne raison que dans ce mode on se laisse gagner très rapidement par du laxisme !

[orafrance]

Envoyé par philcero

Personnellement, je déconseille fortement l'utilisation de l'AUTOEXTEND car c'est un mécanisme dangereux quand on travaille sur des machines mutualisées et/ou à base de baies. La moindre application qui part en vrille et c'est invisible.

L'autoextent n'exempte pas du suivi des l'espace de stockage... ça évite juste de planter une grosse reprise le week-end à cause d'un déficit d'espace alors que tu n'as pas été prévenu des impacts ou d'être un bête robot qui agit manuellement sur une vérification automatique

Envoyé par philcero

D'un point de vue strictement professionnel, la vie des occupations disques est à la charge du DBA et ce pour une simple et bonne raison, il est de sa responsabilité de prévoir l'avenir. Autrement dit de pouvoir capitaliser sur le passé et surtout de parfaitement connaître les us et coutumes des espaces sous sa responsabilité afin de prévoir les besoins notamment en espaces disques. Dans un groupe entre le déclenchement de l'analyse et l'arrivée du matériel il se passe plusieurs semaines et si une base explose pour cause de besoin d'espace disque non prévu, c'est la tête du DBA qui tombe et c'est normal.

Va prévoir le nombre de factures et surtout de lignes de facture, ou de commande ou autres... c'est pas au DBA de fournir ces infos... quand bien même on te dirait qu'il y a 100 factures de 10 lignes /jour de créer, tu serais incapable de connaitre l'impact sur l'espace ne connaissant pas le MCD

Envoyé par philcero

- La deuxième est généralement plus une notion d'espace libre que de ratio. Il faut que tes espaces libres proposent au moins un segment contigu de la taille du plus grand EXTENT de tes objets.

J'ai pas bien compris...

Du coup j'ai 2 questions : pourquoi et comment fais-tu pour éviter le chainage de données ?

[orafrance]

Envoyé par philcero

Quand tu gère des bases pharmaceutiques une appli qui part en vrille doit être maîtrisée le plus vite possible.

Et le crash d'une session pour cause de tablespace plein tu trouves que c'est maitrisé ?

Envoyé par philcero

Dans le cadre d'une base non sensible, un check journalier peut suffire. Dans tous les cas l'historisation des utilisations des espaces disques et entièrement à la charge du DBA et c'est pas en faisant de l'AUTOEXTEND qu'on y arrive pour la simple et bonne raison que dans ce mode on se laisse gagner très rapidement par du laxisme !

euh... j'vois pas en quoi recevoir un mail tous les jours qui te donne le taux de remplissage des tablespaces rend moins laxiste que de faire les stats hebdo ou mensuelle des extensions de fichiers...

Le but de l'AUTOEXTEND c'est d'éviter de perdre du temps sur des tâches récurrentes pour se concentrer sur les vraies problématiques : performances, sécurisation des données, etc... Si être efficace et pro-actif c'est être laxiste alors effectivement, il faut éviter l'AUTOEXTEND

[philcero]

La problématique des ratios est que si ton espace disques est souvent ré-aménagé, celui-ci se fragmente. J'ai déjà vu des cas où pour un tablespace de 10Go plein à 95% (Autrement dit avec 500Mo de libre) ne permettait plus d'extension pour aucun objet contenu pour cause de NEXT_EXTENTs compris entre 5Mo et 10Mo et d'espaces contigus pas plus gros que 2Mo. Du coups la vérification basée sur un ratio pose problème. Elle est bonne en soi si on la prends pour base d'analyse mais il faut la compléter par une recherche des espaces libres et voir combien d'augmentation de mon plus gros NEXT_EXTENT ceux-ci peuvent encaisser.

[orafrance]

Envoyé par philcero

La problématique des ratios est que si ton espace disques est souvent ré-aménagé, celui-ci se fragmente. J'ai déjà vu des cas où pour un tablespace de 10Go plein à 95% (Autrement dit avec 500Mo de libre) ne permettait plus d'extension pour aucun objet contenu pour cause de NEXT_EXTENTs compris entre 5Mo et 10Mo et d'espaces contigus pas plus gros que 2Mo. Du coups la vérification basée sur un ratio pose problème. Elle est bonne en soi si on la prends pour base d'analyse mais il faut la compléter par une recherche des espaces libres et voir combien d'augmentation de mon plus gros NEXT_EXTENT ceux-ci peuvent encaisser.

Oui et ? C'est bien pour ça qu'on réorganise les tablespaces régulièrement mais tu vérifies pas la fragmentation tous les jours quand même ?

Si tu as déjà vu un cas si extrême, t'as probablement vu que le DBA avait pas mal de temps libre dans la journée tant l'administration ne lui prend pas trop de son temps

PS : D'ailleurs, c'est pas pour rien qu'on prend un ratio de 80% pour une alerte et 90% une alerte critique

[philcero]

Cas simple et vécu : Deux administrateurs Oracle pour 72 bases de données réparties sur trois sites (40 de production pure et 32 de développement et autre). Le métier des bases allant du tertiaire au manufacturing avec si indisponibilité de quelques unes un arrêt provoquant d'une dizaine à une centaine de personnes au chômage technique. Les échanges volumétriques/sessions sont tels que les bases sont analysées toutes les 15mn par un automate de manière à ce que les administrateurs réagissent au plus vite en cas de pépin (A venir ou déjà là).

Ce genre de site ne peux en aucun cas se gérer avec un mail quotidien, quand on travaille dans l'industrie les bases sont un outil comme un autre et si il tombe en panne il faut des responsables. Donc tu fais au mieux pour que cela ne tombe jamais en panne...

[olivanto]

Envoyé par philcero

Tout dépends de ce que tu gère. Quand tu gère des bases pharmaceutiques une appli qui part en vrille doit être maîtrisée le plus vite possible. Dans ce cas précis, un check des bases automatisé toutes les 10 minutes permet d'analyser les comportements et de traiter les problèmes en casi temps réel.

Je vais te rassurer ; ce n'est pas parce que tu gère des données sensibles (et je vais te donner un tuyau ; t'es pas seul !) que tu dois passer toutes les 10mn derrière ; je me pose une question --> vous êtes combien dans ton service ????? Parce que s'il faut une personne pour vérifier les tablespaces toutes les 10 minutes ..... Y'en a un qui vérifie aussi la température du CPU ? C'est dangereux un cpu qui chauffe...

En ce qui me concerne, je regarde tous les matins si tout va bien et je délaisse mon rôle de DBA pour faire autre chose.

Faut pas céder à la paranoïa quand même ! Enfin, moi j'ai pas 72 bases à gérer, c'est vrai ... (72 bases....tu bosses où ??)

[orafrance]

Envoyé par philcero

tu fais au mieux pour que cela ne tombe jamais en panne...

et la pro-activité est plus efficace que les alertes il me semble

Dans ce que tu me décris, je ne vois toujours pas l'intérêt de se passer de l'AUTOEXTEND si ce n'est de multiplier les "chances" d'erreur humaine

J'ai moi-même travailler dans des environnements extrêmement critique et j'suis navré mais se retrouver avec des tablespaces qui peuvent même plus accepter un nouvel extent dans un segment c'est de l'incompétence pour moi

olivanto je suis d'accord, si on en est au point de vérifier toutes les 10 minutes c'est qu'on ne se laisse pas assez de marge. Je serais curieux de savoir comment ça se passe quand un problème de perf monopolise la matinée... la moitié des tablespaces explosent parce que personne n'a le temps de vérifier ?