Discussion :

[marvelromy]

Bonjour à tous,

Sur ma base de données je crais toujour des datafiles AUTOEXTEND OFF dans mes tablespaces et Je me demande quelle est véritablement :
- l'avantage,
- l'inconvénant,
- les conséquences

de créer les datafiles en AUTOEXTEND ON car c'est embêtant de toujour créer en AUTOEXTEND OFF?

je sais que quand le datafile est AUTOEXTEND ON cela permet son élargissement de la valeur précisée en paramètre quand il arrive à saturation. mais je les craient toujour AUTOEXTEND OFF.

Aidé moi à briser cette façon de faire par des véritables explications

version: 9i

Merci : j'espère ne pa vous Ennuiyés avec cette préocupation élémentaire.

[LeoAnderson]

Grand débat en perspective !



Les pros diront qu'avec l'autoextend, on ne gaspille pas de place (on ne consomme que ce dont on a besoin) et qu'on ne perd pas de temps à surveiller les occupations.
Les antis diront qu'avec l'autoextend on ne maitrise pas la consommation disque et qu'on ne peut donc pas déceler des comportement anormaux, et que l'on perd du temps en plus lors d'aggrandissement du ficher.

Chacun des arguments avancés se verra contré : si on sauvegarde avec RMan, on ne gaspille pas de place, la surveillance des seuils est automatique donc on ne passe pas de temps, ...


perso, je n'ai pas d'avis !
ça dépend du contexte, de l'architecture, des contraintes, des ressources disponibles, ...

[orafrance]

pas mieux, c'est plus une habitude d'administration qu'autre chose sachant qu'avec la DBConsole toutes les alertes nécessaires à la surveillance

[pat29]

Bonjour,

en général on met AUTOEXTEND ON en développement pour ne pas être embêté par les tablespaces full, car on est souvent sous Windows où l'espace disque n'est pas cher.
En production ils préfèrent souvent le mettre à OFF car les conséquences d'un tablespace full sont moins gênantes qu'un file system full.
De toutes façons dans les 2 cas il faut surveiller quelque chose...

Cdlt.

[scheu]

Le problème c'est que bien souvent comme les développeurs ou les concepteurs d'applis sont incapables de fournir une estimation de la volumétrie, soit tu crées tes datafiles trop grands, soit tu les crées petit mais en autoextend, dans ce cas ils sont toujours à quasiment 100% de taux de remplissage, et il faut envisager une supervision OS au niveau des filesystems plutôt qu'une supervision sur le seuil de remplissage des tablespaces

[dgi77]

Le problème c'est que bien souvent comme les développeurs ou les concepteurs d'applis sont incapables de fournir une estimation de la volumétrie, soit tu crées tes datafiles trop grands, soit tu les crées petit mais en autoextend, dans ce cas ils sont toujours à quasiment 100% de taux de remplissage, et il faut envisager une supervision OS au niveau des filesystems plutôt qu'une supervision sur le seuil de remplissage des tablespaces

Vrai, ça c'est la théorie et c'est très joli.
Sauf qu'en pratique bon nombre de DBA ne surveillent pas non plus assidûment ces taux de remplissage, dans ce cas il vaut mieux qu'ils laissent AUTOEXTEND à ON, sans quoi régulièrement quand on arrive le matin la gueule enfarinée, on trouve les batchs de la nuit qui ont planté :"Unable to extend ..."
Vous connaissez la musique ?

A ce sujet, il paraît que depuis la 9i, on peut dans ce cas-là, agrandir le tablespace, puis reprendre le traitement là où il s'était arrêté. Est-ce que quelqu'un connaît et a des retours d'expérience là-dessus ?

[orafrance]

on trouve les batchs de la nuit qui ont planté :"Unable to extend ..."
Vous connaissez la musique ?

A ce sujet, il paraît que depuis la 9i, on peut dans ce cas-là, agrandir le tablespace, puis reprendre le traitement là où il s'était arrêté. Est-ce que quelqu'un connaît et a des retours d'expérience là-dessus ?

oui c'est le mode RESUMABLE et ça marche très bien

[marvelromy]

Decidement je suis encore moins éclairé avec toutes ces conséquences de part et d'autre.
c'est vrais que chaque matin il faut se jetter sur les tailles pour s'assurer que tout est ok. et si on doit s'absenté tout un week-end, bah on n'a pas la paix au coeur.

Que chacun donne le mode qu'il utilise actuellement et les raisons qui motivent se choix et au moins je pourrais pésé le pour et le contre pour choisir quoi faire.

Merci pour vos interventions.

[scheu]

Je dirais qu'en gros ça dépend de la supervision dont on dispose. Avec la grid console 10g, on peut recevoir des alertes en fonction de seuils définis d'occupation des tablespaces (je l'utilise beaucoup c'est très pratique). On peut aussi scheduler des lancements de scripts SQL dans une crontab qui calcule tous les jours le taux de remplissage de chaque tablespace, et le sortir en rapport quotidien. Si par contre on n'a pas d'outil de supervision des tablespaces et qu'on ne souhaite pas développer de scripts à la main, alors dans ce cas oui il est sans doute préférable de tout laisser en autoextend et de juste superviser le taux d'occupation du disque/filesystem.

Mais le problème de l'autoextend vient du fait qu'on ne maitrise rien sur l'évolution des espaces disques occupés. En autoextend, un tablespace peut s'agrandir jusqu'à faire exploser un filesystem si un utilisateur lance une mauvaise requête accidentellement ou un gros traitement exceptionnel. Dans ce cas les conséquences peuvent être plus graves. Comme dit Pat29, un tablespace full est souvent moins grave qu'un filesystem full

En gros je dirais :
- soit "autoextend off" si derrière on peut superviser régulièrement le taux d'occupation des tablespaces
- soit "autoextend on" mais en surveillant très souvent le taux d'occupation des filesystems mais attention aux traitements exceptionnels et ou mauvaises requêtes utilisateur qui peuvent faire exploser le TEMP ou le UNDO si elles sont mal conçues

Un bon compromis est le "autoextend on" avec un maxsize, en gros on autorise un datafile à s'étendre mais jusqu'à une certaine limite en calculant cette limite pour ne pas dépasser la taille du filesystem. Mais si plusieurs datafiles en autoextend grossisent en même temps, le filesystem sera quand-même saturé avant que chaque datafile ait atteint le maxsize (ça m'est très souvent arrivé ça et c'est imprévisible).

Bref dans tous les cas, il y a des risques.

Personnellement je n'utilise jamais l'autoexend, je surveille les taux d'occupation de mes tablespaces et dès qu'ils atteignent un certain seuil (85% par exemple), je reçois une alerte, j'agrandis un peu le datafile (RESIZE) pour faire redescendre le taux en dessous du seuil (genre 75-80%), etc ... en faisant ça continuellement. En gros sur une base je fais un resize tous les 2-3 mois maximum si la base ne grossit pas trop vite, et ça limite les risques

[scheu]

c'est vrais que chaque matin il faut se jetter sur les tailles pour s'assurer que tout est ok

Supervision quasiment obligatoire (sinon bon courage ) ! Genre script qui calcule les tailles et t'envoie par mail le compte rendu tous les matins, c'est trop dur à faire et bien pratique ;-)

[orafrance]

Personnellement je n'utilise jamais l'autoexend, je surveille les taux d'occupation de mes tablespaces et dès qu'ils atteignent un certain seuil (85% par exemple), je reçois une alerte, j'agrandis un peu le datafile (RESIZE) pour faire redescendre le taux en dessous du seuil (genre 75-80%), etc ... en faisant ça continuellement. En gros sur une base je fais un resize tous les 2-3 mois maximum si la base ne grossit pas trop vite, et ça limite les risques

Moi aussi parce que je vois un autre intérêt... agrandir bêtement le tablespace c'est pas trop ma tasse de thé. Si des tablespaces se mettent à grandir de manière régulière ça va m'alerter sur les choses à étudier :
- partitionning
- purge
- réorg
- clause storage inadapté
- objets créés de manière sauvage

etc...