about News
OLR/OCR/VOTING, kesako?
- Détails
- Catégorie : News
- Publié le mercredi 7 octobre 2015 19:22
- Écrit par Administrator
- Affichages : 55729
Il y a souvent confusion entre l’OCR (Oracle Cluster Registry) et les voting disks. Pourtant ils ont des rôles bien différents. Leur seul point commun est l’obligation lors d’une installation Oracle RAC 11gR2 (et plus) avec ASM d’être mis dans le même storage (même diskgroup). En effet à l’installation on indique les disks ASM qui vont former le diskgroup « initial » et va stoker l’OCR (je dis bien OCR et pas les OCR) et les voting disk (je dis bien les voting disks et pas le voting disk).
Je vais donc dans cet article expliquer à quoi servent l’OCR et les voting disk, mais aussi détailler où ils se cachent et sous quelle forme. Mais avant je rajouterai un autre fichier : l’OLR (Oracle Local Regitry) bien souvent méconnu et pourtant tout aussi critique lors du démarrage du cluster sur un noeud. De plus du fait de son nom il peut y avoir une confusion avec l’OCR alors que leur rôle et leur stockage sont totalement différents.
12c : recover table l'usine à gaz
- Détails
- Catégorie : News
- Publié le dimanche 20 septembre 2015 19:28
- Écrit par Administrator
- Affichages : 45527
La 12c apporte son lot de nouveauté, ou plutôt apportait, elle n’est plus trop nouvelle la 12c maintenant.
Quand j'avais lu la liste, une nouveauté avait particulièrement retenu mon attention : RMAN peut restorer une table. Je me suis dit il va falloir tester cela, c'est complètement révolutionnaire!
Un backupset étant composé de plusieurs blocs "mélangés" de datafiles, RMAN saurait allait rechercher dans les blocs les données d'une table. Cela signifierait donc que RMAN saurait lire dans les backupsets un peu comme le noyau Oracle dans les datafiles !
Sachant que normalement le nom de la table n'est pas écrite dans l'entête des blocs, alors cela signifierait que RMAN saurait retrouver les metadata dans le tablespace SYSTEM qui lui aussi est potentiellement répartie sur plusieurs backupsets. De plus il faut aussi ensuite lire les backupsets des archivelog car la table est peut être sur plusieurs datafiles et donc chaque datafile au moment du backup n'avait pas le même SCN, cela veut dire rejouer uniquement les logs des transactions pour une table donnée ou plus globalement pour les datafiles contenant la table.
J’ai donc testé cette nouvelle « feature »…quel naïf, j'aurais dû me doutais qu'il y avait anguille sous roche.
News about 12.1.0.2 : documentation et SE2
- Détails
- Catégorie : News
- Publié le dimanche 13 septembre 2015 14:27
- Écrit par Administrator
- Affichages : 50746
Oracle a récemment mis à jour sa documentation et sorti une nouvelle version dans sa distribution 12.1 : la SE2
Mais commençons par une news qui n’intéressera presque personne. La documentation Oracle vient de changer d’infographie. Elle n’avait pratiquement pas évolué depuis la 10g, et les changements d’avant la 10g n’avaient jamais été aussi « marquant ». Le changement semble s’être fait entre les versions 12.1.0.1 et 12.1.0.2. L’article « passionnant ! » retraçant les évolutions de la documentation Oracle database a été mise à jour (L'encyclopédie du DBA).
TDE wallet in multi database environment
- Détails
- Catégorie : Sécurité
- Publié le dimanche 14 juin 2015 20:01
- Écrit par Administrator
- Affichages : 9103
Dans l’article TDE (Part I) nous avions configuré TDE pour la base de données ARKONA en RAC. Une wallet contenant la mastrer key, avait été générée. L’emplacement de la wallet est configuré dans le fichier sqlnet.ora se trouvant dans le répertoire TNS_ADMIN par défaut ($ORACLE_HOME/network/admin).
[oracle@racdb1 admin]$ cat sqlnet.ora
ENCRYPTION_WALLET_LOCATION = (SOURCE =(METHOD = FILE) (METHOD_DATA =(DIRECTORY =/oracle/oraBase/wallet)))
Mais voilà, maintenant il nous faut gérer sur ce même cluster le chiffrage par tablespace d’une deuxième base de données. Comment faire sachant qu’une wallet ne peut appartenir qu’à une seule base de données ? Et en plus il faudra configurer des connexions par SSL pour chacune des bases et donc gérer de nouvelles wallet. (la mise en place SSL sera fait dans un prochain article).
Dbvisit Standby : le test (prise en main)
- Détails
- Catégorie : Dataguard
- Publié le dimanche 15 février 2015 20:11
- Écrit par Administrator
- Affichages : 14133
Cet article décrit comment installer, paramétrer et manager Dbvisit Standby. Même si l’outil permet de gérer des standby (et pas des Dataguard), il se trouve dans la rubrique Dataguard, le but de l’outil étant de remplacer de Dataguard en rajoutant une couche logicielle sur un Standby.
L’installation software
Le soft peut être téléchargé >ici<. On peut demander une licence temporaire pour tester. La licence dure 1 mois alors je vous conseille de préparer vos bancs de test avant. La version tester dans le présent article est la 7.0.22.
Nous allons installer DBStandby sur 2 serveurs de base de données : oradbm2 et oradbm3 en Oracle Linux 6.6. Sur oradbm2 tourne une base de données nommé WINDB en file system sur un moteur 11.2.0.4. Sur oradbm3, il y a juste un moteur 11.2.0.4.
Un prérequis avant l’installation est de mettre en place le ssh équivalence entre les 2 comptes oracle (comme lors de l'installation RAC voir : testbed : 11gR2 RAC ASM ). Une fois cela mis en place, l’installation peut commencer, elle est assez simple :