Overblog
Suivre ce blog Administration + Créer mon blog
21 février 2010 7 21 /02 /février /2010 14:19

Bonjour,

Lors de précdents articles, j'avais abordé le thème de Dataguard que ce soit une version light en Oracle Standard Edition ou la version incluse avec Oracle Enterprise.

Et bien maintenant avec  ORACLE 11g, il faudra ajouter une troisième variante.... et cela s'appelle Oracle DataGuard Active.

Vous allez me dire "Quelles différences avec le Dataguard sous Oracle 10g ?"

Et bien je vais aborder deux différences majeures....


-1 / Le prix !

Pour bénéficier de Oracle Dataguard Active, il faut non seulement disposer d'une version enterprise, mais il faut de surcroit s'affranchir de ce que Oracle appelle succintement "un extra cost". Bref, il faut payer !!

-2/ Payer, Ok mais pour quel(s) avantages ?

L'avantage principale réside dans le nom "Active" ! Cela signifie que contrairement à la version classique de Dataguard, la base de secours (Appelée Standby) peut rester ouverte (et donc accessible en lecture seule) durant l'application des archives log provenant de la base principale (appelée Primary).

Rappel: Avec Oracle 10g, la standby devait être en mode "Mount" durant l'application des archives log.


Magique ! Non seulement vous disposez d'une base de secours, et histoire de ne pas "gaspiller un serveur" uniquement pour éventuellement un problème durant les prochaines années,vous pouvez l'utiiser comme référentiel pour tout ce qui décisionnel (BO, ou autres outils).

Au final; dans certaines architectures nous avions
-1 Un serveur principal (pour le transactionnel)
- 2 Un serveur de secours (Dataguard)
- 3 Un serveur pour le décisionnel

Avec cette nouvelle fonctionnalité sous Oracle 11, on peut ainsi  s'économiser  un environnement, puisque 2 et 3 pourront se confondre.


On peut bien sur avec Oracle 10g décider d'ouvrir la base standby en lecture seule et rejouer le delta entre la primaire et la standby la nuit. Cepandant cela à l'inconvénient majeur que durant une période de la journée, le delta entre la base primaire et celle de secours soit conséquent. Par conséquent en cas de perte de l'instance primaire, la durée d'interruption de service peut être conséquente (le temps de rejourer les archivelogs de la journée).

Il existe d'autres nouveautés liées à Oracle Dataguard Active, mais j'en garde un peu pour la prochaine fois.

Durant les prochaines semaines (enfin j'espère), je vais rédiger un article pour la mise en place d'un standby Active sous Oracle 11g.....

Par ailleurs, veuillez trouver ci-dessous mon profil viadeo (pour ceux  & celles qui désirent monter un réseau de DBA). On ne sais pas de quoi l'avenir est fait !
http://www.viadeo.com/fr/profile/laurent.allio


Articles utiles à la compréhension:

Dataguard - Présentation
Dataguard - Physical Standby - Mise en place
Dataguard - Version standard - Mise en place d'une base "standby" (1)
Dataguard - Version standard - Mise en place d'une base "standby" (2)

Heureux d'être de retour. !!

LAO.

Partager cet article
Repost0
30 novembre 2008 7 30 /11 /novembre /2008 20:05

Bonsoir,

Et voici donc le dernier petit post pour le mois de novembre. Et je ne vais pas faire original en vous parlant d'une petite nouveauté ORACLE 11.

Pour cela, on peut utiliser une petite table T3 (i number) de 40 millions de lignes (ca marche aussi avec moins ou plus de lignes).

Admettons que je veuille  ajouter une colonne j de type number non nullable et avec une valeur par défaut 12.

Au niveau syntaxe, rien d'extrordinaire.



ALTER TABLE T3 ADD (j NUMBER DEFAULT 12 NOT NULL);


La syntaxe est la même avec ORACLE 10 et ORACLE 11. En revanche ce qui est différent, c'est le temps pour executer la commande.

ORACLE 10 : Au bout de 140 heures (et vu qu'ORACLE m'annoncait encore 150 heures) j'ai rennoncé à ajouter ma colonne.

ORACLE 11 : Instantanée

En fait sous Oracle, l'ajout de la colonne avec une valeur par défaut entraine la mise à jour des 40 millions de lignes !! Alors qu'Oracle 11 utilise une métatable pour stocker la valeur par défaut. Seules les nouvelles valeurs seront insérées avec la valeur par défaut. En revanche, si je fais une requête sur des données portant avant l'ajout de la colonne, Oracle effectuera de manière transparante une jointure avec la metatable.

Ceci est notamment utile dans des environnements décisionnels. En effet, il est fréquent que les tables aient plusieurs millions de lignes. Par ailleurs, pour des problèmes de durée de sauvegarde, certaines données du passé sont placées sur des tablespaces en READ ONLY, ce qui evidemment est en opposition avec la possibilité d'effectuer une misa à jour.

Cela est valable aussi pour les colonnes "not null" avec des valeurs par défaut qu'avec des colonnes calculées (http://www.lao-dba.com/article-25070818.html)


LAO.

Partager cet article
Repost0
26 novembre 2008 3 26 /11 /novembre /2008 20:33

Bonsoir,

Oracle 11 offre la possibilité de conserver le résultat d'une requête en cache. Pour cela, il suffit d'ajouter le hint /*+ resultat_cache */ dans votre requête. Alors allons y pour la preuve par l'exemple:

Pour cela, j'ai un user lao qui dispose d'une jolie table T3(i number,j number) de 40 millions de lignes, et je suis amené à faire des select count(*) dessus régulièrement.



sqlplus /nolog
connect lao/lao

SET AUTOTRACE ON
SELECT COUNT(*) FROM T3;


Résultat des courses :

Temps d'execution :9 secondes

60868 consistent gets et autant de lectures physiques, et globalement j'aurai le même résultat en rejouant la requête plusieurs fois.

Utilisons notre hint.


SELECT /*+ result_cache*/ COUNT (*) FROM T3;


Résultat:

La première execution donne bien evidemment le même résultat que sans le hint.

Mais la ou cela devient interessant, c'est lors des autres appels que ce soit dans ma session en cours ou depuis une autre session. Le résultat devient instantané et pour cause, puisqu'Oracle va chercher uniquement le résultat en cache.

Deux constatations:

  1. On peut voir dans le plan d'execution l'apparition d'une ligne indiquant pour la colonne opération "Result cache". Ce qui nous montre bien qu'ORACLE soit allé chercher l'information dans le cache.
  2. On peut également constater, dans les statistiques 0 consistent gets et 0 lecture physiques. Ce qui explique le coté instantané du résultat.


Remarque: Il convient d'utiliser cette technique sur des tables relativement statiques et savoir que potentiellement le résultat de la requête ne refletera pas la réalité du moment.

LAO.









Partager cet article
Repost0
25 novembre 2008 2 25 /11 /novembre /2008 19:59

Bonsoir,

Et aujourd'hui une petite nouveauté au niveau table. Il est en effet possible avec Oracle 11 de mettre une table en lecture seule alors qu'avant il n'était possible de le faire qu'au niveau tablespace. 

La syntaxe est très simple :



ALTER ma_table READ ONLY;


De même pour revenir en mode écriture la syntaxe est :



ALTER TABLE ma_table READ WRITE;


Par ailleurs, une nouvelle colonne "READ_ONLY" a été ajouté dans les vues DBA_TABLES, USER_TABLES, ALL_TABLES. Cette colonne prends les valeurs YES et NO.

LAO.

Partager cet article
Repost0
23 novembre 2008 7 23 /11 /novembre /2008 19:10

Bonsoir,


Encore une petite nouveauté ORACLE 11. Avec sa nouvelle version, Oracle a introduit la notion de colonne virtuelle. Un mot savant pour présenter ce qui n'est ni plus ni moins qu'un champs calculé.

D'ailleurs, ceux qui ont eu l'occasion de travailler avec SQL SERVER doivent se dire "Et bien il était temps", car cette fonctionnalité existe au moins depuis SQL SERVER 2000 (j'ai un doute sur SQL7).

Juste pour la forme un petit exemple tout simple. Une table de facture avec un montant HT, le taux de TVA, et partir de la on va pouvoir avoir la TVA et TTC. Et cela bien sur sans passer par un trigger ou un calcul avant insertion



CREATE TABLE Facture

(

NumeroFacture NUMBER,

MontantHT FLOAT,

TVA FLOAT,

MontantTVA AS (MontantHT*TVA/100),

MontantTTC AS (MontantHT+(MontantHT*TVA/100))

);




Remarque 1: Il n'est pas nécessaire d'indiquer un type pour les colonnes virtuelles.


Remarque 2: Il n'est pas possible de créer une colonne virtuelle contenant elle même dans son expression une colonne virtuelle.


Remarque 3: Il est tout a fait possible d'indexer ce type de colonne, et d'utiliser ce type de colonne comme clé de partition.


LAO.


Partager cet article
Repost0
23 novembre 2008 7 23 /11 /novembre /2008 10:56

Bonjour,


On continue un peu avec les "petites nouveautés" d'ORACLE 11.

Avant ORACLE 11, lorsque vous vouliez récupérer la dernière valeur d'une séquence il fallait passer par la table "DUAL" avec quelque chose comme ca



SELECT my_seq.NEXTVAL INTO my_var FROM DUAL;

Et bien avec ORACLE 11, on peut simplifier notre code de la façon suivante:


my_var :=my_seq.NEXTVAL;



Bien evidemment, je vous conseille de n'utiliser cette syntaxe qu'uniquement si votre environnement est totalement ORACLE 11. Car si vous vouliez portez votre code sur une version antérieure, cela ne fonctionnerait pas.

Il ne semble pas y avoir de différence de performance entre les deux possibilités.


LAO.


Partager cet article
Repost0
18 novembre 2008 2 18 /11 /novembre /2008 20:51
Bonsoir,

Nous y voila. Ma machine virtuelle est prête. Alors allons y !
Je commence par me connecter en system.
juste pour la forme, je vérifie le nombre de paramètres pour mon instance.


SELECT COUNT(*) FROM v$Parameter;


Résultat :288 paramètres et autant de raisons de faire en sorte que rien ne fonctionne correctement..., ce qui en fait quand même 31 de plus que ma bonne vielle 10.2.0.1 


Je vais me créer un petit user pour la suite.


CREATE USER LAO IDENTIFIED BY LAO;
GRANT CONNECT, RESOURCE TO LAO;



Ouvrons une session sqlplus et connectons nous en LAO

connect lao/lao;

Damned !!! ORA-01017: Invalid username/password; logon denied ....

Ce bon vieux Oracle serait devenu fou !
Et bien non, avec Oracle 11 le mot de passe est SENSITIVE !

Et je fais comment avec mon environnement et ses 150 applications configurées avec des mots de passe indiqués un coup en minuscule un coup en majuscule ....
 
Et bien, c'est simple je me rappelle qu'ORACLE s'est toujours arrangé pour avoir la plus grande compatibilité ascendante et que donc il doit bien y avoir un paramètre pour modifier cette option.

Et dans  la doc, on trouve le fameux paramètre: SEC_CASE_SENSITIVE_LOGON

Dans ma session SYSTEM,


ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=FALSE;



Et voila je peux  me connecter aussi bien en lao/lao que lao/LAO et encore lao/LaO

Des la connexion Oracle nous gratifie donc d'une nouveauté ...

Ne soyons pas radin et attaquons de suite la suivant, toujours axée sur la sécurité.

Lors d'un audit de sécurité sur une base Oracle une des première chose à vérifier est que la base n'utilise pas de compte avec les mots de passe par défaut (genre scott/tiger,...)
Le souci, c'est que qu'il faut :
  • Connaitre les comptes par défaut
  • Connaitre leur mot de passe
  • Se les faire un par un (ou créer un script) pour vérifier que ces mot de passe ont bien été changé la ou l'on fait l'audit.

Ca n'est pas super gratifiant et c'est franchement chiant.
Alors merci à ORACLE qui nous gratifie d'une nouvelle vue DBA_USERS_WITH_DEFPWD
 

Il suffit d'intérroger cette vue pour connaitre instantanément quels sont les comptes qui le mot passe par défaut.

Je concède que ca n'est pas transcendant comme nouveauté, mais il fallait bien commencer par quelque chose, et finalement parler un peu de la connexion reste logique !
Encore un peu de patience....

LAO.
 
Partager cet article
Repost0