Blog - comments

Hi Perry, The spare CPU power is of course available for other processes ( i.e non-caged database)! ...
When I studied Oracle New Feature Guide "Media Failure: PDB SYSTEM Data File" , I was surprised tha...
Hayat Khan

Really a nice article to study.

Thanks,

Amol Bhoite

Bonjour,

Tout d'abord merci pour cet article. J'aimerai savoir si ACFS est gratuit ?

Chris

Chris
Hi Jerome.. I have a question. Suppose if we have 8 CPUs on server and we assign 2 CPUs to a databas...
Perry Kahlon
Blog Pierre Boizot Resource FAILOVER dans Grid Infrastructure

dbi services Blog

Welcome to the dbi services Blog! This blog focuses on IT infrastructure - featuring news, troubleshooting, and tips & tricks. It covers database, middleware, and OS technologies such as Oracle, Microsoft SQL Server, Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on the postings!

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.

Resource FAILOVER dans Grid Infrastructure

Dans le cadre d'un cluster Oracle Grid Infrastructure 11g R2 utilisé pour gérer des bases de données en mode FAILOVER, j'ai été amené à me pencher sur l'algorithme de basculement d'une ressource et des paramètres le régissant.

 

On trouve dans la documentation Oracle des informations sur les cinq paramètres intervenant dans la prise de décision, à savoir:

  • CHECK_INTERVAL: L'Intervalle de temps entre deux exécutions d'une action de vérification.
  • RESTART_ATTEMPTS: Le nombre de tentatives de redémarrage d'une ressource sur le serveur local avant une tentative de déplacement.
  • UPTIME_THRESHOLD: Le temps nécessaire pour que la ressource soit considérée comme stable par Oracle Clusterware.
  • FAILURE_THRESHOLD: Le nombre de défaillances détectées pendant l'intervalle FAILURE_INTERVAL pour que la ressource soit considérée comme indisponible.
  • FAILURE_INTERVAL: L'intervalle en secondes, pendant lequel Oracle Clusterware prend en compte la valeur de FAILURE_THRESHOLD.

 

Robert Bialek, dans un article intitulé "Oracle Database Failover Cluster with Grid Infrastructure 11g R2", nous donne une explication claire de l'algorithme de gestion de la ressource bien qu'il omette la prise en compte de l'heure du dernier FAILOVER.

 

Je voudrais dans cet article apporter quelques précisions sur l'arbre de décisions. Rappelons-nous qu'à chaque intervalle de temps CHECK_INTERVAL, la ressource est testée. Nous pouvons décrire le pseudo algorithme suivant:

 

Tantque ressource_active faire

attendre CHECK_INTERVAL ;

si ( Check ( ressource) 0 ) alors

si (RESTART_COUNT < RESTART_ATTEMPTS ) alors

restart

RESTART_COUNT ++

sinon

si ( FAILURE_COUNT < FAILURE_THRESHOLD -1 ) alors

failover

RESTART_COUNT = 0 

FAILURE_COUNT ++

FAILURE_HISTORY = date+hostname

sinon

si ( interval(dernieredate(FAILURE_HISTORY), DateCourante ) > FAILURE_INTERVAL ) alors

failover

RESTART_COUNT = 0 

FAILURE_COUNT ++

FAILURE_HISTORY = date+hostname

sinon

stop de la resource

message CRS-2771:Maximum restart attempts reached for resource ;

finsi

finsi

finsi

 

Le paramétrage suivant...

 

FAILURE_INTERVAL=3600

FAILURE_THRESHOLD=2

PLACEMENT=restricted

RESTART_ATTEMPTS=2

UPTIME_THRESHOLD=4h

 

...autorisera deux redémarrages locaux (paramètre RESTART_ATTEMPTS=2), un basculement vers un autre nœud (FAILURE_THRESHOLD=2) puis deux redémarrages locaux au second nœud ( RESTART_ATTEMPTS=2).

 

Un cinquième incident entraînera un arrêt de la ressource s'il intervient moins d'une heure après le premier FAILOVER (FAILURE_INTERVAL=3600 ). À partir de cet instant, c'est la fréquence de l'incident (temps entre deux FAILOVER > FAILURE_INTERVAL=3600) qui conditionnera la relocalisation d'un nœud vers un autre.

 

Pour une ressource de type base de données, 5 incidents (crash) dans 1 heure de temps, c'est beaucoup.

La mise à 1 du paramètre RESTART_ATTEMPTS peut être envisagé pour que l'on analyse plus rapidement les causes de ces redémarrages fréquents.

 

Rate this blog entry:
2

Pierre Boizot est Principal Consultant chez dbi services. Il bénéficie de 25 ans d’expérience dans le domaine des bases de données. Son parcours du traitement de la donnée à la gestion de son hébergement lui permet aujourd'hui d’avoir une très bonne expérience et compréhension des infrastructures techniques système et bases de données. En tant que consultant indépendant durant 8 ans, Pierre Boizot a évolué dans divers environnements, acquérant ainsi autonomie et de nouvelles connaissances, et renforçant sa capacité à mettre en œuvre des environnements hautement disponibles et performants. D’un esprit ouvert, curieux et innovateur, doté d’une grande capacité d’écoute et d’une bonne disponibilité, il met ses compétences au service de ses interlocuteurs pour réaliser et atteindre les objectifs fixés.

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Thursday, 24 April 2014
AddThis Social Bookmark Button
Deutsch (DE-CH-AT)   French (Fr)
NewsOfficesContact

Contact

Contact us now!

Send us your request!

Our workshops

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

Expert insight from insiders!

Fixed Price Services

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

A safe investment: our IT services at fixed prices!

Your flexible SLA

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

ISO 20000 certified & freely customizable!

dbi services Newsletter