Rechercher dans ce blog

mercredi 5 octobre 2011

Services Oracle en Environnement RAC





Configuration et Gestion des Services Oracle en Environnement RAC  








A) Gestion des Services

1) Qu’est ce qu’un service ?

Un service sert à regrouper des sessions au cours desquelles le même type de travail est exécuté. Il offre des fonctions de gestion de la charge globale, il sert de base à la haute disponibilité des connections et offre une nouvelle dimension pour le réglage des performances «Service et SQL» remplace «Session et SQL».

2) Création d’un service

A l’aide des interfaces standards telles dbca, EM (Entreprise Manager), l’utilitaire srvctl et le package DBMS_SERVICES, vous pouvez créer, configurer, administrer, activer, désactiver et mesurer un service.

Pour la configuration de notre application,  on a retenu l’utilitaire srvctl et le package DBMS_SERVICES.

3) Description de l’architecture :

Mtlunt8
Mtlunt9
BD : ADOP
Instance 1  : ADOP1@Mtlunt8
Instance 2  : ADOP2@Mtlunt9


Pour le déploiement de cette architecture, stockés dans le référentiel du cluster (OCR : Oracle Cluster Registry) afin d’être gérés par le CRS  Clusterware d’oracle.

Service  L_PBSTSC_CI  : Ce service sera disponible sur les deux nœuds mtlunt89  et  mtlunt97.
Il  sert  pour  la lecture des schemas PBSTSC_CI..
Un  compte   et   un role   oracle  sont associsés


Le service L_PBSTSC_CI   sera configuré pour gérer l’équilibrage de charge entre les deux nœuds en utilisant la fonction de conseil du LBA (Load Balancing Advisory).

4) Configuration des services

a) Création des services
$ srvctl add service -d ADOP -s L_PBSTSC_CI -r ADOP1,ADOP2 

-d: Le nom de la base de données
-s: Le non du service
-r: Instances pré-sélectionnées
-a: Instances disponibles en cas d’incidents.

b) Démarrage des services

$ srvctl start service -d ADOP -s L_PBSTSC_CI
c) Arrêt des services
$ srvctl stop service -d ADOP -s L_PBSTSC_CI
d) Configuration et statut d’un service

$ srvctl config service -d ADOP
$ srvctl status service -d ADOP1


C) Equilibrage de Charge des Connexions

L’équilibrage de charge des connexions permet aux processus d’écoutes (listeners) de distribuer des demandes de connexions aux meilleures instances. Des mesures de performances sont utilisées par les listeners pour la prise de décision et pour sélectionner  l’instance la mieux adaptée. Ce choix dépend de l’objectif d’équilibrage de charge (GOAL) défini pour le service.

On active la fonction de conseil LBA, lorsqu’on affecte la valeur DBMS_SERVICE.GOAL_SERVICE_TIME ou  DBMS_SERVICE.GOAL_THROUGHPUT à l’objectif du service.

1) Service_time : Temps de réponse du service.
2) Throughput  : Débit du service (Quantité de travail terminé en une unité de temps).

Les processus d’écoutes utilisent le paramètre DBMS_SERVICE.CLB_GOAL, pour distribuer les connexions. Ce dernier possède les valeurs suivantes :

1) Clb_goal_short : Utilisation de la fonction de conseil LBA
2) Clb_goal_long  : Utilisation du nombre de session par service.

Pour gérer côté serveur l’équilibrage de charge et configurer la fonction d’enregistrement dynamique de la performance des services, il faut attribuer un nom TNS décrivant la liste des tous les processus d’écoute disponibles au paramètre d’ initialisation REMOTE_LISTENER de chaque instance. Ainsi, sur la base des informations sur la charge calculées par la fonction LBA et envoyées par chaque processus PMON, le listerner1 (Nœud : MTLUNT97) redirige la demande de connexion entrante vers le listener2 (Nœud : MTLUNT89) sur lequel le service correspondant fonctionne le mieux et vis versa.

Paramètre  en  11g
remote_listener                       ADOPCRS:1521

D) Configuration de la fonction TAF

Cette fonction permet à une application de se reconnecter automatiquement au service si la connexion initiale échoue. Pendant la reconnexion, les transactions actives font l’objet d’une annulation (Rollback), mais la fonction TAF donne la possibilité de reprendre l’exécution d’une instruction SELECT qui était en cours.

Cette fonction prend en charge deux méthodes de gestion des incidents :

1) BASIC : La connexion est rétablie au moment de l’incident.
2) PRECONNECT : Cette méthode est semblable à la méthode BASIC, à ceci près qu’une connexion de secours est créée pendant la connexion initiale afin d’anticiper les éventuels incidents.

Pour notre configuration on a retenu la première méthode. Pour activer cette dernière,  il faut utiliser l’utilitaire srvctl  et l’option –P BASIC à la création du service.

L’application doit se connecter au service via un descripteur de connexion. Le paramètre FAILOVER_MODE doit être inclus dans la section CONNECT_DATA du descripteur.

1) TYPE : Définit le type de gestion des incidents et à pour valeurs :
Ÿ         SESSION : Signifie que seule la session utilisateur est authentifiée à nouveau côté serveur. Les curseurs ouverts dans l’application doivent être réexécutés.
Ÿ         SELECT : Signifie que non seulement la session est authentifiée à nouveau côté serveur,  mais encore les curseurs ouverts peuvent également poursuivre les fetchs.

2) METHOD : BASIC est utilisé pour rétablir une connexion au moment de l’incident.
3) RETRIES : Permet d’indiquer le nombre de tentatives de connexions après incidents.
4) DELAY : Permet de définir le délai, en secondes, entres les tentatives de connexions.

E) Définitions des Services et des Descripteurs de Connexions

Les services sont utilisés dans le fichier tnsnames.ora pour influencer quel noeud est à utiliser pour chaque application.
1) Service L_PBSTSC_CI
1.1) Création du service
$ srvctl add service -d ADOP -s L_PBSTSC_CI -r ADOP1,ADOP2
1.2) Démarrage du service
$ srvctl start service -d ADOP -s L_PBSTSC_CI
1.3) Activation de la fonction LBA
BEGIN
DBMS_SERVICE.MODIFY_SERVICE (service_name => L_PBSTSC_CI '  
                            , goal => DBMS_SERVICE.GOAL_SERVICE_TIME 
                            , clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);
END;
1.4) Descripteur de connexion côté client
L_PBSTSC_CI =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = AdopCRS)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = L_PBSTSC_CI)
    )
  )

mardi 4 octobre 2011

rman backup incremental

Multilevel Incremental Backups
RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1.
A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data.
The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.


A level 1 incremental backup can be either of the following types:
■ A differential backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0
■ A cumulative backup, which backs up all blocks changed after the most recent incremental backup at level 0Incremental backups are differential by default.


The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.


Note: Cumulative backups are preferable to differential backups  when recovery time is more important than disk space, because
fewer incremental backups need to be applied during recovery.


Incrémental  différentiel  de level 1   :


Backup   incremental  level  cumulatif :

On  backup  tout  depuis   le  backup full  tous  les jours.





On peut  évidemment  faire un mix

dataguard 11g le switch over avec et sans broker

         Switch  over :

6.     Standby (aix_rac2) :

·      Verification de  la bonne  synchronisation de la standby :
Sur  la  primaire 
Archive log list;
Oldest online log sequence     26
Next log sequence to archive   28
La sequence  courante  est la   27.
Sur la  standby   avec  la  requete de  verification on est  aussi  a la   sequence  27.

·      Arrêter le  recover managed
alter   database recover  managed  standby database cancel;
·      Verification de la log db
·      Verification  du  switchover status :
select switchover_status from v$database;
to  primary
·         le  switch :
                    alter database commit to switchover to primary;
                    shutdown  immediate
                    startup
                    select  database_role  from  V$database;
                    alter  system  switch  logfile;

7.     Primaire (aix_rac1) :

                    alter database commit to switchover to standby;
                    shutdown  immediate
                    startup mount
                    select  database_role  from  V$database;
alter  database  recover  managed  standby  database disconnect  from  session;

 VI.            Broker

Avant  meme  de  demarrer  voila  la configuration par  defaut  sur la   primaire :
SQL> show  parameter  broker
NAME                                                                          VALUE
dg_broker_config_file1                    /u01/app/oracle/11.2.0/dbs/dr1 MG.dat
dg_broker_config_file2                     /u01/app/oracle/11.2.0/dbs/dr2MG.dat
dg_broker_start                                FALSE
alter  system set  dg_broker_config_file1=’ +data/MG/DATAGUARDCONFIG/dr1 MG.dat ';
alter  system  set dg_broker_config_file2='+FRA/MG/DATAGUARDCONFIG/dr2 MG.dat ';
Si  on met  les  fichiers de   config   sur  le  meme  dg  on recoit  l erreur  ORA-02097
Sur les 2  serveurs  je  demarre  le  broker  (process  dmon)
alter   system  set dg_broker_start=true;
Dans le  broker :
create  configuration dguard as  primary  database is 'MG' connect  identifier is 'MG';
add  database ‘MGSTDBY’ as  connect   identifier  is ‘MGSTDBY’ maintained  as  physical;
enable   configuration;
·         administration du  broker :
Show  configuration ;
DGMGRL> show  configuration;

Configuration - dguard

  Protection Mode: MaxPerformance
  Databases:
    MG      - Primary database
      Warning: ORA-16789: standby redo logs not configured

    MGSTDBY - Physical standby database
      Error: ORA-16797: database is not using a server parameter file

Fast-Start Failover: DISABLED

Configuration Status:
ERROR
Correction   de  ses erreurs
Sur MG@aix_rac1
ALTER DATABASE ADD STANDBY LOGFILE '+data';   quatre fois.

Sur MGSTDBY@aix_rac2
SQL>  ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracledata/arch/MGSTDBY/stdbylog/stdbylog1'  size 104857600;
SQL> ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracledata/arch/MGSTDBY/stdbylog/stdbylog2' size 104857600;
SQL> ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracledata/arch/MGSTDBY/stdbylog/stdbylog3' size 104857600;
SQL> ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracledata/arch/MGSTDBY/stdbylog/stdbylog4' size 104857600;
Create spfile   from pfile;
Shutdown immediate
Startup  mount
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
  
DGMGRL> show  configuration;
Configuration - dguard
  Protection Mode: MaxPerformance
  Databases:
    MG      - Primary database
    MGSTDBY - Physical standby database (disabled)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> show  database  verbose 'MG';
Voila  les  properties :

DGConnectIdentifier
'MG'
ObserverConnectIdentifier
''
LogXptMode
'ASYNC'
DelayMins
'0'
Binding
'optional'
MaxFailure
'0'
MaxConnections
'1'
ReopenSecs
'300'
NetTimeout
'30'
RedoCompression
'DISABLE'
LogShipping
'ON'
PreferredApplyInstance
''
ApplyInstanceTimeout
'0'
ApplyParallel
'AUTO'
StandbyFileManagement
'MANUAL'
ArchiveLagTarget
'0'
LogArchiveMaxProcesses
'4'
LogArchiveMinSucceedDest
'1'
DbFileNameConvert
'/u01/app/oracledata/stdby, +DATA/MG/datafile, /u01/app/oracledata/stdby, +DATA/MG/tempfile'
LogFileNameConvert
' /u01/app/oracledata/stdby, +DATA/MG/onelinelog'
FastStartFailoverTarget
''
StatusReport
'(monitor)'
InconsistentProperties
'(monitor)'
InconsistentLogXptProps
'(monitor)'
SendQEntries
'(monitor)'
LogXptStatus
'(monitor)'
RecvQEntries
'(monitor)'
HostName
'aix_rac1'
SidName
'MG'
StaticConnectIdentifier
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.180)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=MG_DGMGRL)(INSTANCE_NAME=MG)(SERVER=DEDICATED)))'
StandbyArchiveLocation
'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation
''
LogArchiveTrace
'0'
LogArchiveFormat
'%t_%s_%r.dbf'
TopWaitEvents
'(monitor)'



DGMGRL> show  database  verbose 'MGSTDBY';
·         La log du   broker  est 
$diag_dest/rdbms/<$ORACLE_SID>/<$ORACLE_SID>/trace/drc<$ORACLE_SID>.log

8.     Bascule  dataguard  avec  le  broker :

Elle  peut  se faire  a distance  mais  je  fais  ca depuis    un des serveurs  impliqué dans  la   configuration.
switchover  to ‘MGSTDBY’; ( dep uis  le role standby  vers le  primaire).
DGMGRL> switchover  to 'MGSTDBY';
Performing switchover NOW, please wait...
New primary database "MGSTDBY" is opening...
Operation requires shutdown of instance "MG" on database "MG"
Shutting down instance "MG"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "MG" on database "MG"
Starting instance "MG"...
Unable to connect to database
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

Failed.
Warning: You are no longer connected to ORACLE.

Please complete the following steps to finish switchover:
        start up and mount instance "MG" of database "MG"

DGMGRL>
Apres   stop/start de la  base MG@aix_rac1
DGMGRL> show   configuration;

Configuration - dguard

  Protection Mode: MaxPerformance
  Databases:
    MGSTDBY - Primary database
    MG      - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS
Les  db   sont   synchrones .
Retoure  sur  MG :
switchover   to 'MG';
startup  de  MGSTDBY;
Remarque :
Avec   le   broker  la   standby  passe   de facon automatique  en  mode  recover  managed.

9.     Fast-start  Failover (P438/439):

Moyen de   basculer   automatiquement   selon des  cas  bien  precis  sans  intervention :
Offline  datafile
Corruption  du   dictionnaire , du  controlfile
Logfile  innacessible
Stuck  archiver
Threshold,….
Commande  pour  mettre  ca   en place
Dgmgrl>Enable  fast_start failover condition ‘XXXXX’;
                Show  fast_start  failover;
On peut avoir  en  plus  un observer :
L observer   est  sur  un autre  serveur .

VII.            Clusterware  to  manage  service applicatif

Ca  fontionne pas  encore  .

http://uhesse.wordpress.com/2010/09/06/data-guard-oracle-restart-in-11gr2/