Discussion :

[leng]

Bonjour à tous;
j'ai des sérieux ennuis avec Oracle 10 release 2.

en voulant faire la commande suivante:
create rollback segment r01 tablespace tbrbs;

j'obtient l'erreur ora 30574 ( qu'il ne peut creer un role back segment dans ce type de tablespace.

Question: comment créer mon tablespace tbrbs pour pouvoir creer mon rollback segment?

[orafrance]

Tu ne travailles pas avec un UNDO ?

[leng]

Non pas de UNDO

[orafrance]

j'savais même pas que les rollback existaient encore en 10g... Tu ferais mieux de migrer en UNDO c'est bien plus avantageux

Sinon : http://ora-30574.ora-code.com/

Il te faut un tablespace DICTIONNARY MANAGED apparemment

[Elise78]

Bonjour tout le monde :-)

Je me permets de relancer ce post étant donné que j'ai eexactement le même problème. J'ai justement des questions à ce sujet.

j'savais même pas que les rollback existaient encore en 10g... Tu ferais mieux de migrer en UNDO c'est bien plus avantageux

Je travaille sur une migration 8i->10g. Passer à une nouvelle version ne sous-entends pas forcément une prise en compte de toutes les évolutions de la nouvelles versions cible (malheureusement )

Sinon : http://ora-30574.ora-code.com/

J'ai beau essayé d'autres tablespaces (TMP, RBS_11 ou RBS_12), j'ai la même erreur

Code :

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

1
2
3
4
5
6
7
TABLESPACE_NAME                EXTENT_MAN ALLOCATIO
------------------------------ ---------- ---------
SYSTEM                         DICTIONARY USER
SYSAUX                         LOCAL      SYSTEM
TMP                            LOCAL      UNIFORM
RBS_11                         LOCAL      UNIFORM
RBS_12                         LOCAL      UNIFORM

Il te faut un tablespace DICTIONNARY MANAGED apparemment

C'est à dire ? Je suis perdue à ce moment là !


Elise78 (qui en a ras le bol de pleurer )

[Wurlitzer]

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLESPACE RBS3 DATAFILE 
  'c:\repertoire\rbs.dbf' SIZE 1024K AUTOEXTEND OFF
LOGGING
DEFAULT STORAGE ( 
                  MAXEXTENTS  UNLIMITED
                )
PERMANENT
EXTENT MANAGEMENT DICTIONARY
/

Tu auras un tablespace DICTIONNARY MANAGED comme SYSTEM et non pas LOCALLY MANAGE comme (SYSAUX , TEMP, RBS_11 et RBS_12)

Elise78 (qui en a ras le bol de pleurer )

C'est pas joli, joli de nous prendre par les sentiments

[orafrance]

Je travaille sur une migration 8i->10g. Passer à une nouvelle version ne sous-entends pas forcément une prise en compte de toutes les évolutions de la nouvelles versions cible (malheureusement )

Alors tu t'enléves tout l'intérêt de la migration... quel est l'objectif si tu n'utilises pas les nouveautés ?

C'est à dire ? Je suis perdue à ce moment là !

Tes tablespaces RBS doivent être en DICTIONNARY MANAGED (cf article sur les tablespaces) mais encore une fois, j'insiste sur le fait que c'est complétement imbécile surtout en 10g. C'est comme si tu faisait installer l'électricité chez toi mais que tu refusais de t'éclairer autrement qu'avec des bougies et que tu faisais la lessive à la main

[Pomalaix]

Je travaille sur une migration 8i->10g. Passer à une nouvelle version ne sous-entends pas forcément une prise en compte de toutes les évolutions de la nouvelles versions cible (malheureusement )

Et concrètement, qu'est-ce qui vous empêche d'utiliser un tablespace UNDO ?
Vous avez des procédures qui utilisent des commandes de ce type ?

Code :

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

SET TRANSACTION USE ROLLBACK SEGMENT xxx

[Marc Musette]

10g offre du support, 8i n'est plus officiellement supportée --> intérêt de migrer quand même

effectivement ne pas utiliser le UNDO management est un sérieux désavantage

qui plus est passer de l'un à l'autre ne demande pas beaucoup d'effort si ce n'est de traquer les SET TRANSACTION en début de session , et surtout de savoir quelle undo retention configurer !

bonne chance

[Elise78]

Hello world

Alors je vais essayer de répondre à toutes les questions. Commencons par le début !!

1-
Wurlitzer, je suis désolée, effectivement c'est pas jolie, mais c'est vrai et c'est fatiguant !


2-
Le but premier de la migration est l'évolution de la plate-forme (passer d'un AIX qui à 7 ans à un Linux sur IBM) qui nous offre déjà à lui seul une optimisation des temps d'exécution des traitements en passant de 10h à 1h30 (voire moins).
Ensuite effectivement Oracle 8i n'est plus supporté.
Certaines des évolution 10g sont prises en compte, mais l'intégration des UNDO nécessiterait une refonte de l'applicatif qui n'est pas à l'ordre du jour.
Sait-on jamais cela pourrait changer d'ici que je finisse mon portage technique.
Pour le moment j'opère une migration à iso-fonctionnalité sans modification majeure de la structure du code et de la base. En somme je dois pouvoir installer un dump de production sur cette machine !
Dans un deuxième temps il sera éventuellement question d'une optimisation et rafraichissement de l'environnement base de données ... qui sait ?
En somme oui Fred_D, je lave encore mon linge à la main, mais le SAV me dit qu'il ne pourra intervenir que si j'ai l'electricité


Elise78

[Elise78]

Voici ce que j'essaye de faire.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SQL> CREATE TABLESPACE RBS
2  DATAFILE '/data/ora/BASE/u01/rbs/rbs_11.dbf'   SIZE 400M REUSE
3  DEFAULT STORAGE (INITIAL 1M NEXT 1M MAXEXTENTS 505 PCTINCREASE 0) ;
Tablespace created.
 
SQL> CREATE ROLLBACK SEGMENT demarrage;
Rollback segment created.
 
SQL> ALTER  ROLLBACK SEGMENT demarrage ONLINE;
Rollback segment altered.
 
SQL> CREATE ROLLBACK SEGMENT RBS_01 TABLESPACE RBS
STORAGE (INITIAL 400K NEXT 400K MINEXTENTS 10 OPTIMAL 4000K);
2  CREATE ROLLBACK SEGMENT RBS_01 TABLESPACE RBS
*
ERROR at line 1:
ORA-30574: Cannot create rollback segment in tablespace 
with AUTO segment space management

Elise78

[orafrance]

l'option était pourtant en gras dans le message : EXTENT MANAGEMENT DICTIONARY

[remi4444]

je vais briser ce joli consensus....
le UNDO a un très gros inconvéniant, c'est que son tablesapce peut saturer très facilement de manière difficilement controlable étant donné que la rétention est définie avec un temps et non un volume maximum. Lorsqu'on a une base très actives et peu volumineuse, ça demande beaucoup plus de place qu'avec les RBS et surtout ça peut faire apparaitre des nouvelles erreurs de saturation.
Surtout, on arrive à un paradoxe génant qui est qu'une optimisation des temps de traitements peut mener à une erreur de saturation du undo (car si pour un intervalle donné il y a plus de mises à jour qui passent, alors les données stockées pendant le temps de rétention sont plus grosse...). Et bonjour la galère pour expliquer à un utilisateur que ses traitement tournent trop vite... (c'est du vécu! )

Attention, je ne dis pas que les rollbacks sont mieux, je veux simplement dire que tous les arguments ne sont pas du même coté...

[Elise78]

Merci Remi4444 de cette précision, je ne serai pas surprise si cela devait m'arriver

Sinon pour ce qui est de mon script, ca se passe plutot bien. Il ne me reste plus que l'import à lancer et vérifier si ca tourne convenablement, avec une simulation de prod.

Merci tout le monde.

Elise78

[orafrance]

Remi il me semble que tu te méprends sur le UNDO. En effet, le undo_retention n'est qu'une cible, Oracle favorisera toujours la mise en UNDO plutôt que le undo_retention. Donc c'est une erreur de penser que le UNDO augmente à cause du undo_retention. Ainsi, le UNDO n'est pas plus volumineux que les RBS

[remi4444]

Ah oui c'est parceque c'est une 10g non ? c'est en 9 que j'étais tombé sur un os...

ci joint une tite discussion qu'on avait eu sur ce sujet...

http://www.developpez.net/forums/sho...d.php?t=218779