Discussion :

[delphim]

Voici mon problème : j'ai un datafile de 3 GO, que je souhaite réduire à 2 GO.
Malheureusement, il y a des données au-délà des 2 GO, ce qui fait que je ne peux réduire mon datafile en-deça de 2,9 GO.

Comment faire pour réduire la taille du datafile dans ce cas ?

Est-ce une question de fragmentation des données ?
(je crée et je détruis souvent des schémas sur mon instance).

[orafrance]

tu n'as pas d'autres choix que de transférer les objets dans un autre tablespace le temps de recréer le premier

[Marc Musette]

peut-être devrais-tu songer à opter pour un tablespace par user/schéma ; tu pourrais ainsi dropper physiquement les datafile lorsque tu supprimes tes schémas

[orafrance]

A noter que si c'est un tablespace qui contient des indexes un REBUILD de ceux-ci peut suffire

Je préconise de faire au moins deux tablespaces : un pour les tables et un pour les indexes.

A mon avis l'idéal est de faire 6 tablespaces : petites/moyennes/grosses tables et leurs pendant pour les indexes

[delphim]

ah oui j'ai oublié de préciser : c'est pour un datafile du tablespace USERS

[orafrance]

USERS de 3 Go... à mon avis tu as des objets que tu devrais déplacer dans un tablespace spécifique

[Marc Musette]

effectivement un tablespace par user te simplifiera la vie

séparer les index et les tables peuvent effectivement t'offrir de meilleures performances (mais te compliquer néanmoins la vie pour gèrer les tablesspaces)

par contre Megadub, quels sont les avantages (et les explications) d'avoir des tablespaces différents selon la taille des des tables ... le tablespace est selon moi, une strucrure logique qui est là pour faciliter la gestion, la maintenance et permettre une plus grande disponibilité de la db (un tablespace COMPTA offline n'empêche pas le tablespace GESTION d'être disponible) ???

[orafrance]

Si tous les tablespaces sont sur le même disque cette architecture ne changera rien aux perfs, en revanche les accés concurrents sur les fichiers peuvent être particulièrement optimisés si tous les tablespaces bénéficient d'un axe d'I/O propre

A part ça, c'est surtout lors des grosses réorg de base que cette architecture prend tout son sens puisque tu peux réorganiser les tablespaces les uns après les autres. En fait, la séparation par taille est un abus de logique , l'idéal étant une séparation par fréquence d'update/delete/insert.

Je pars du principe que les grosses tables sont bcp insérées et rarement deletées donc les opérations de réorg seront moins fréquentes contrairement aux petites tables qui bougent bcp et risquent de générer les lignes chainées et de la fragmentation dans le tablespace.

Et là, en terme d'administration t'es bien content de pouvoir transférer tous les objets dans un autre tablespace pour la réorg sans être "parasité" par les gros objets qui ne t'intéressent pas

J'espère que mon explication, si elle ne te convaint pas, sera au moins suffisament clair

[orafrance]

Pour en revenir à l'idée de faire un tablespace par shéma pour ne pas impacter les autres shémas, cela me semble assez difficile de toutes manières car rares sont les MPD où les shémas sont parfaitements cloisonnées. Par exemple CLIENTS (gestion des clients, contacts et toutes leurs infos perso) impactera forcément les autres shémas, donc l'intérêt d'un tel cloisonnement est intéressant sur le papier mais finalement en pratique j'ai rarement réussi à faire une réorg propre sans impacter une grosse parti de l'appli.

En revanche, avec la solution que je propose, tu peux te permettre de faire des réorg des plus petits objets + souvent parce que le process sera très rapide

[SheikYerbouti]

Séparation physique sur des disques différents s'entend.

[orafrance]

comme je l'explique, si ils sont sur des axes I/O séparés tu parallélises les traitements sur les datafiles

[orafrance]

Séparation physique sur des disques différents s'entend.

farpaitement

Sinon, pour moi, je trouve qu'il y a quand même un intérêt au niveau de l'admin (comment ça je me répéte )

[Marc Musette]

...Ceci dit, il me parait intéressant de séparer les index des tables mais uniquement pour simplifier l'administration de la base.

moi je pense tout le contraire : c'est plus simple d'avoir un tablespace par application (index + table), c'est un tout-en-un ; au niveau perf, par contre, c'est tout le contraire : lors d'un insert par exemple ... il y abien deux endroits à aller écrire ...

de toute façon, je crois que ma solution et celle de Megadub sont bonnes mais adaptées à des situations différentes : 1 tablespace par application (même par user) c'est possible dans le cas d'applic compactes (non datwarehouse) facilement cloisonnables (crois-en mon expérience, c'est possible aussi ) ; on peut toujours vouloir scinder tables et index pour éviter ces fameux "contention IO" mais de nouveau il faut peser le pour et le contre ; de même dans de grosse base de données on peut créer trois tablespaces de taille et d'extent différents (mais aujourd'hui avec les locally managed tablespaces quid ?)


http://asktom.oracle.com/pls/ask/f?p...6047656036459,[/quote] pour quelques remarques à ce sujet

[orafrance]

de toute façon, je crois que ma solution et celle de Megadub sont bonnes mais adaptées à des situations différentes

Exactement

et c'est le même constat pour quasiment tous les choix qui touchent à la performance

[delphim]

Je pense qu'il faut séparer ces 2 types d'objets pour que Oracle puisse tirer partie du parallélisme offert par l'architecture matérielle du serveur (lecture des index et des tables en même temps car situés dans des datafiles différents).

Bien plus, je dispose d'un serveur avec 3 disques, donc le parallélisme n'est plus limité par le contrôleur de disque, puisque les tablespaces sont sur des disques physiques différents.

[orafrance]

exemple :

TABLE toto (ID -> PK, VALUE)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ID from toto

-> pas d'accés sur le datafile des data, alors moi MEGADUB je persiste à dire que ça peut être intéressant

Mais, il est vrai que l'intérêt que j'y trouve est surtout pour l'administration des objets

[Yorglaa]

et quid de l'option "croisée" sur 2 disques ?

disque 1 = data 1 et index 2
disque 2 = data2 et index 1

votre avis ?

[Patmane]

http://asktom.oracle.com/pls/ask/f?p...:5071430793941

don't separate them for performance reasons, there aren't any

Fait il référence à une architecture physique particulière (SAN par exemple) ou parle t'il de séparation des data et des index de manière générale? En tout les cas, merci BrunoJ pour cette info

[Marc Musette]

Merci Bruno pour cet article : au moins voila une bonne réponse claire et explicite

personnellement, mon application utilise un tablespace parce qu'à l'époque, je ne connaissais pas encore le mythe "séparer index et table" ... depuis je l'ai connu, je l'ai même défendu et je me suis dit : "il faut absolument que je repasse dans mon applic pour modifier ces index/tables ..."

fainéant de nature, je ne l'avais pas encore fait et voila que Dieu, Tom Kyte et surtout BrunoJ viennent me récompenser de ma fainéantise ... pour une veille de weekend, je trouve cela parfait

bon ben le revers de la médaille dans tout cela c'est un ras le bol par rapport à un nombre impressionnant d'auteurs respectés (respectables ?) tels que Kevin Loney (nom de **** il est quand même publié par OraclePress pour ses DBA Handbook depuis la version 7 minimum...) qui semble raconter des idioties ... souvenons-nous du SELECT COUNT(1) plus rapide que le COUNT(*), des curseurs explicites de Feuerstein (aussi démontés par T. Kyte) etc ... idem pour les study guide d'Oracle concernant les certifications ... apparemment rédigés par des rigolos vu le nombre d'erreurs, de mythes, de suppositions ... moi qui rêvait d'une certif oracle, je crois que je vais laisser tomber tant la politique de ces certifs m'écoeurent et qui plus est, si c'est pour apprendre des choses fausses ...

heureusement le forum Developpez.net existe ! merci à tous pour votre savoir et surtout savoir-faire !!!

sur ce, bonne fin de semaine

Marc

[/b]

[orafrance]

et quid de l'option "croisée" sur 2 disques ?

disque 1 = data 1 et index 2
disque 2 = data2 et index 1

votre avis ?

c'est clairement l'idéal

Toujours selon moi évidemment et je suis loin de pouvoir rivaliser avec T. Kyte

Marc_Musette -> il ne faut pas non plus prendre tout au pied de la lettre même dans les articles de T. Kyte. Il faut aussi se rappeller que certaines recommendations sont hérités des versions antérieures d'Oracle et que les choses changes

Pour le COUNT(1), je ne suis pas encore convaincu par son article parce que si il montre que les accés aux données sont strictement identiques, je ne me rappelle pas avoir vu quoi que ce soit sur le parsing... je pensais que COUNT(NULL) était mieux parce qu'il évite le hard parse à chaque fois et l'article ne dément pas cette hypothése (dans mes souvenirs )

M'enfin... les COUNT de toutes façons doivent représenter environ 0.0001% des requêtes exécutées, alors cette réflexion tient plus de la masturbation intellectuelle que d'un apprentissage certain à mon avis