Discussion :

[Mothership]

Bonjour,

DBA débutant, nous gérons au sein de notre société une base Oracle installé sur Windows, utilisé pour notre ERP SAP.
L'espace utilisé par les données et indexes commencent à réellement nous poser des problèmes, aujourd'hui elle atteint les 1,8To.
Notre fenêtre de maintenance est très courte, environ 4 heures le dimanche après midi et je me demande comment peut on efficacemenet regagner de l'espace sur cette base.

Nos tests d'expdp/impdp sont plutôt concluant, mais la génération des Indexes est notamment très chronophage, certaines tables ne pourront sans doute pas être exportée/importée pendnat ces 4 heures qui nous sont allouées.
Des réorganisations de tables sont planifiées quotidiennement, mais de la même manière nous ne disposons pas d'assez d'espace pour réorganiser des tables grosses de plus de 300 Go.

Question annexe sur les sauvegardes, sur une sauvegarde FULL à chaud, nous mettons aujourd'hui 3 ou 4 heures pour sauvegarder l'ensemble de nos données, cela vous parait il cohérent, nous utilisons 2 lecteurs LTO4 via fibre optique ?

J'aurai aimé avoir un retour d'expérience sur ces sujets

[farenheiit]

vous pouvez essayez d'utiliser le mode compression de stockage de tables et des indexes.
J'ai réussi à diviser par 3 l'espace de stockage grâce à la compression.

[orafrance]

Question annexe sur les sauvegardes, sur une sauvegarde FULL à chaud, nous mettons aujourd'hui 3 ou 4 heures pour sauvegarder l'ensemble de nos données, cela vous parait il cohérent, nous utilisons 2 lecteurs LTO4 via fibre optique ?

Ca parait pas délirant, par contre, tu ferais bien de te pencher sur les sauvegardes incrémentielles.

Après pour ton problème d'espace, as-tu regardé la taille des segments et la fragmentation des tablespaces ?

[Z3phur]

Bonjour,

pour ces 3 ou 4h de sauvegarde, quelle est la taille des données sauvegardées?

[Mothership]

Z3phur
environ 1,6 To, regroupant nos tablespaces, quelques fichiers systèmes et les REDO pour la consistance de la base.

orafrance
Concernant les incrémentielles, je n'étais pas suffisamment confiant sur notre logiciel de sauvegarde notamment sur la partie ORACLE/SAP (logiciel Data Protector). Une fois le système éprouvé, il est vrai que nous pourrions mettre en place ce genre de job en marche.
Pour la restauration d'un job incrémental, il faut j'imagine la sauvegarde complète de début de semaine.
Imaginons :
Sauvegarde complète le dimanche matin (faible activité)
Sauvegarde Incrémentale le lundi en fin d'après midi
Sauvegarde Incrémentale le mardi en fin d'après midi
Sauvegarde Incrémentale le mercredi fin d'après midi

Problème le jeudi matin, pour restaurer la base complète du Mercredi, faut il les bandes du Dimanche + lundi + mardi + mercredi ?
Ou faut il les cassettes du Dimanche + mercredi ?


farenheiit
Concernant la compression des données, est-ce au détriment des performances ? Car ces tables sont encore utilisées.
La compression choisit elle des données anciennes ou faiblement utilisées/consultées/modifiées ?

[farenheiit]

la compression peut avoir des effets benefiques sur les select (car moins de blocs à lire)
par contre ça peut avoir qq effets nefastes sur les DML.
mais globalement ça reste correct

[orafrance]

orafrance
Concernant les incrémentielles, je n'étais pas suffisamment confiant sur notre logiciel de sauvegarde notamment sur la partie ORACLE/SAP (logiciel Data Protector). Une fois le système éprouvé, il est vrai que nous pourrions mettre en place ce genre de job en marche.
Pour la restauration d'un job incrémental, il faut j'imagine la sauvegarde complète de début de semaine.
Imaginons :
Sauvegarde complète le dimanche matin (faible activité)
Sauvegarde Incrémentale le lundi en fin d'après midi
Sauvegarde Incrémentale le mardi en fin d'après midi
Sauvegarde Incrémentale le mercredi fin d'après midi

Problème le jeudi matin, pour restaurer la base complète du Mercredi, faut il les bandes du Dimanche + lundi + mardi + mercredi ?
Ou faut il les cassettes du Dimanche + mercredi ?

Si tu utilises RMAN, qui est toujours associé aux outils de backup, il n'y a rien à craindre.

Personnellement, je fais une full/mois (incrémentale 0), une incrémentale de niveau 1 par semaine et un backup des archives tous les jours : http://oracle.developpez.com/guide/s...rde/rman/#L1.3

Dans ce cas, il faut le niveau 0 + niveau 1 + les archives depuis la dernières niveau 1 sur bande.

Enfin, vu le prix des disques, franchement, c'est balot de se prendre la tête sur l'espace... tu fais acheter un disque de 500Go et basta

[Mothership]

J'avoue être un peu frileux et bloqué sur mes tests RMAN et malgré pas mal de documentation sur Internet et celle créée par orafrance.
En effet nos environnements de tests sont plus dédiés aux fonctionnels qu'a la technique, ainsi un mauvais paramétrage, une boulette quelconque entrainant l'arrêt de l'environnement et c'est retour de baton de la part de nos fonctionnels et de nos développeurs.
Certains paramètres sont un peu paniquant dans le sens ou je n'ai aucune idée de quoi mettre comme la vitesse, la concurrence des traitements etc. J'imagine que seul les tests me permettront d'avancer en commençant petit jusqu'à atteindre les performances / temps de sauvegarde souhaité.


Merci pour ces informations !

[Z3phur]

Question annexe sur les sauvegardes, sur une sauvegarde FULL à chaud, nous mettons aujourd'hui 3 ou 4 heures pour sauvegarder l'ensemble de nos données, cela vous parait il cohérent, nous utilisons 2 lecteurs LTO4 via fibre optique ?

tu fais tes sauvegardes avec quel utilitaire? RMAN ou autre?

[Mothership]

Le logiciel HP Data Protector utilise les outils SAP (BRTOOLS / BACKINT / BRARCHIVE) pour sauvegarder la base de données.
Le fonctionnement est très proche des outils oracle natif, cela nous permet de voir dans SAP le bon fonctionnement des sauvegardes (et éviter qu'il crie au viol si nous les faisions autrement).