Commentaires du blog: My Oracle blog

Commentaire de LAO

Wed, 31 Aug 2011 15:12:48 +0200

Merci.. J'ai corrigé l'erreur. LAO.

Commentaire de donny

Wed, 31 Aug 2011 15:02:00 +0200

salut,

interessant pour un débutant en optimisatioon comme moi

juste un trucs,je crois qu'il y a une erreur de frappe, c'est plustôt 487 et non 587

Et de facon plus significative 587 accès disques contre 801 avec notre indexe fragmenté. Car maintenant nous pouvons parlé d'indexe fragmenté

Commentaire de LAO

Wed, 31 Aug 2011 08:28:04 +0200

J'y pense tous les jours..... Mais c'est un peu comme le sport, difficile de s'y remettre mais pas forcement pour les mêmes raisons..

Commentaire de Daniel

Wed, 31 Aug 2011 08:06:28 +0200

Hello,

Faux départ....je pensais à un retour de ta part sur ton blog !!

Commentaire de LAO

Wed, 31 Aug 2011 07:40:28 +0200

Merci pour le "remerciement". Ca fait toujours plaisir de savoir que ce qu'on fait peut être utile ! @+

Commentaire de Ferdinand

Mon, 29 Aug 2011 22:22:50 +0200

Bonjour, juste pour dire merci pour cet article qui m'a bien édifié sur le clonnage de la Base de données.

Bonne continuation

A+ Ferdinand

Commentaire de LAO

Sun, 10 Jul 2011 18:53:07 +0200

Hello; Merci pour l'info. pour les articles, l'envie est présente, mais je dois réussir à dégager du temps. @+

Commentaire de DROE

Sun, 10 Jul 2011 13:04:34 +0200

Bonjour Lao,

Attention, je viens de m'apercevoir qu'en 10g c'est

LOGGING_LISTENER = OFF dans listener.ora et non TRACE.....=OFF

Sinon, tu n'ecris plus d'articles ??

Daniel

Commentaire de LAO

Tue, 29 Mar 2011 11:25:55 +0200

Ok, j'avais pu vu le coté "exercice". Fais moi signe lorsqu'il est terminé. Je toujours preneur de bon conseils ! @+

Commentaire de Cédric

Tue, 29 Mar 2011 10:03:15 +0200

Bonjour Lao, merci pour ta réponse.
Concernant l'autobackup, non, il n'est pas activé, ce serait trop simple !
Il faut voir cet article comme un exercice, je mettrai les recommandations quand je le terminerai.

Commentaire de LAO

Tue, 29 Mar 2011 07:09:44 +0200

Bonjour,

J'ai lu votre article. Très interessant et complet.

Sinon pour le probleme de controle file. A-il été backupé ? Par défaut la valeur du paramètre RMAN "CONTROLFILE AUTOBACKUP" est à OFF. Il faudrait refaire le test avec en ayant configuré à ON avacnt de faire les backup.

LAO

Commentaire de Cédric

Mon, 28 Mar 2011 22:54:06 +0200

Tests en cours pour une sauvegarde à froid avec RMAN : http://www.mysqlplus.fr/2011/03/sauvegarde-a-froid-avec-rman-pas-si-simple/

Commentaire de LAO

Wed, 02 Feb 2011 14:17:14 +0100

Bonjour, J'avais écris un petit article sur la désinstallation / installation (par script): http://www.lao-dba.com/article-25766784.html C'était sur du 10gR2 (y a peut être des adaptations pour la 11g). Sinon, il suffit de l'installation via DBCA. @+ LAO

Commentaire de Jean-Michel

Wed, 02 Feb 2011 09:41:16 +0100

Merci LAO pour votre réponse et la deuxième tentative a été la bonne :)
Maintenant, je souhaiterais pouvoir configurer une console EM pour cette nouvelle base clonée. Savez-vous comment faire ?

Encore merci et excellente journée

Jean-Michel

Commentaire de LAO

Fri, 28 Jan 2011 13:14:13 +0100

Bonjour, A l'époque le test était avec une 10g donc je ne "certifie " pas que cela fonctionne sous 11gR2, même si je pense qu'il ne doit pas y avoir de soucis. Juste pour remettre le contexte. Il s'agit d'un clonage mais sur la même machine (il y a également deux autres articles sur le clonage). Donc la base d'origine démarre avec pfile (ou spfile). Mais pour la base destination, je suis obligé de créer un pfile (le fameux init.ora). C'est ce fichier que j'utilise plus loin dans la base pour démarrer l'instance cible. "STARTUP NOMOUNT pfile='c:\ORACLE\PRODUCT\10.2.0\admin\pfile\init.ora';" Evidemment vous êtes libre au niveau des chemins. @+ LAO

Commentaire de Jean-Michel

Wed, 26 Jan 2011 10:01:10 +0100

Bonjour,

Je rencontre un problème avec votre procédure de clonage. J'ai suivi vos instructions mais suite à la commande 'DUPLICATE TARGET DATABASE TO DBDUP' (ma base vide s'appelle DBDUP et celle qui contient les schémas d'origine s'appelle DBJMN) il faut renseigner le fichier init.ora. Dans votre commande 'pfile='C:ORACLEPRODUCT10.2.0adminpfileinit.ora', je ne sais pas de quel init.ora il 'sagit. Logiquement, il doit s'agir du init.ora de ma base vide DBDUP.

Je précise encore que j'utilise votre procédure de clonage avec un serveur Oracle 11gR2 tournant sous Windows XP Pro. Est-ce incompatible avec votre procédure de clonage ?

Voici les messages d'erreurs:

canal ORA_AUX_DISK_1 : dÚmarrage de la restauration de l'ensemble de sauvegarde des fichiers de donnÚes
canal ORA_AUX_DISK_1 : restauration de fichier de contr¶le
canal ORA_AUX_DISK_1 : lecture de l'ÚlÚment de sauvegarde D:ORACLEFLASH_RECOVERY_AREADBJMNBACKUPSET2011_01_26O1_MF
_NCSNF_TAG20110126T090216_6MZOB1CQ_.BKP
canal ORA_AUX_DISK_1: ORA-19504: Úchec de crÚation du fichier "D:ORACLEFLASH_RECOVERY_AREADBDUPCONTROL02.CTL"
ORA-27040: erreur lors de la crÚation du fichier : crÚation impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 3) Le chemin d'accÞs spÚcifiÚ est introuvable.
ORA-19600: le fichier d'entrÚe est control file (D:ORACLE112DBORADATADBDUPDBDUPCONTROL01.CTL
Fin de restore dans 26/01/11

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande Duplicate Db Ó 01/26/2011 09:21:37
RMAN-03015: une erreur s'est produite dans le script stockÚ Memory Script
RMAN-06136: erreur ORACLE provenant de la base de donnÚes auxiliaire : ORA-00205: erreur lors de l'identification du fic
hier de contr¶le; consultez le journal d'alertes

Ayant constaté que le sous-répertoire DBDUP n'existait pas sous FLASH_RECOVERY_AREA, je l'ai créé puis j'ai relancé l'ensemble des commandes sans me reconnecter à RMAN = rman target sys/oracle@DBJMN auxiliary / et j'ai obtenu un autre message d'erreur que voici:

RMAN> duplicate target database to DBDUP pfile='D:OracleadminDBDUPpfileinit.ora'
2> logfile
3> 'D:Oracle112DBoradataDBDUPDBDUPredo01.dbf' size 50m,
4> 'D:Oracle112DBoradataDBDUPDBDUPredo02.dbf' size 50m,
5> 'D:Oracle112DBoradataDBDUPDBDUPredo03.dbf' size 50m;

DÚmarrage de Duplicate Db dans 26/01/11
utilisation du canal ORA_AUX_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Úchec de la commande Duplicate Db Ó 01/26/2011 09:31:56
RMAN-05520: non-concordance des noms de base de donnÚes : DBJMN dans l'instance auxiliaire et DBDUP dans la commande

Sauriez-vous me dire ce qui se passe et quelle est la solution à ce problème ?

Cordiales salutations
Jean-Michel

Commentaire de Eminos

Sun, 09 Jan 2011 15:34:17 +0100

Bonjour,

SVP j'ai crée le fichier init.ora sous pfile

et j'ai lancer crée l'instance

mais lorsque je lance

Commentaire de LAO

Mon, 27 Dec 2010 16:10:40 +0100

Merci ! Et bonne fêtes de fin d'année !

Commentaire de Fr

Thu, 02 Dec 2010 10:50:50 +0100

Belle démonstration.

Merci

Commentaire de LAO

Tue, 16 Nov 2010 10:54:24 +0100

Bonjour,

D'exemple vécu :non. Mais je pense que sur une forte volumétrie cela peut avoir un impact. On a beau tailler une SGA élevé, dans le cas de traitement batch ou décisionnel qui feraient des FULL sur de grosses tables, on ne pourra pas avoir toute la base en mémoire et par conséquent, si on peut limiter les IO en supprimant le chainage (si il devient conséquent ) peut avoir un impact.

Sinon j'ai vu que tu avais également un blog sur Oracle. Je peux l'ajouter dans mes liens si tu le désires.

Commentaire de elche

Wed, 10 Nov 2010 22:22:42 +0100

la problématique des lignes chainées est-elle toujours un pb dans le environnements actuels en 10g ou 11g associé un serveur /san.

As-tu un exemple précis de dégradation de performance liée à ce phénomène ? qui est décrit dans les bouquins de tuning mais que je n'ai jamais observé. A partir du moment où tu paramètres convenablement ta sga pour avoir un bon hit ratio, l'overhead engendré par les listes chainées me parait marginal.

Commentaire de LAO

Tue, 12 Oct 2010 16:09:48 +0200

Merci pour les remerciements !

LAO

Commentaire de Hamid

Tue, 12 Oct 2010 11:32:03 +0200

Bonjour,

Merci pour cet article simple et clair.

Cdlt,

Hamid

Commentaire de Hamid

Tue, 12 Oct 2010 11:30:19 +0200

Bonjour,

Merci pour cet article simple et clair.

Cldt,

Hamid

Commentaire de LAO

Thu, 23 Sep 2010 09:10:12 +0200

Oui ! Bon reste quand même le fait que des que log.xml atteint 10 MO un fichier log_1.xml (et ainsi de suite) est crée et le xml.log est automatiquement purgé.

LAO.