Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

SCOM 2007 : Script de résolution d’alertes

Il peut arriver de devoir passer par un script de résolution d’alertes pour pouvoir nettoyer régulièrement certaines alertes de la console tel que les alertes d’échec de script. Le script suivant est fait pour cela.

Remplacez le nom FQDN_DU_SERVEUR_SCOM  par le fqdn de votre serveur SCOM

Créez une tache planifiée et faites exécuter la commande toutes les heures par exemple en fonction de la fréquence de ces alertes:

“powershell.exe –noninteractive –file chemin_du _script

 

#ce script est executé par tache planifiée tout les jours a 00:00 et clos les

#alertes de nommées ‘Script or Executable Failed to run’

#ou ‘Discovery Probe Module Failed Execution’dont la date de #modification est superieur a #maintenant moins 24 heures.

#Initialisation du provider Ops Mgr 2007 

add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin;

set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;

new-managementGroupConnection -ConnectionString:FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

set-location FQDN_DU_SERVEUR_SCOM -ErrorVariable errSnapin;

#Checks to see if it failed or succedded in loading the provider

if ($errSnapin.count -eq 0)

{

Write-host "`nOpsMgr 2007 PSSnapin initialized!";

}

else

{

Write-host "OpsMgr 2007 PSSnapin failed initialize! Please verify you are running this script on a OpsMgr 2007 Management Server";

}

$alerttoclose = get-alert | where-object {$_.Name -eq "Script or Executable Failed to run" -or $_.Name -match "^.*Discovery Probe Module Failed Execution"} | where-object {$_.resolutionstate -ne ‘255’} | where-object {$_.LastModified -gt [DateTime]::Now.Addhours(-24) }

foreach ($alert in $alerttoclose)

{

$alert | resolve-alert

}

SQL Server 2008 : Types de sauvegardes et choix du mode de récupération d’une base de données

Introduction

Lors de la création d’une base de données SQL Server 2008 on peut choisir le mode de récupération à appliquer pour cette base de données. Ce choix ne doit pas être fait au hasard mais il doit répondre aux besoins de l’entreprise en termes de stratégie de sauvegarde et de récupération.

Types de sauvegardes

SQL Server 2008 offre une multitude de types de sauvegarde pour une base de données sauf que ces types de sauvegarde dépendent du mode de récupération choisi pour celle-ci.

Les types de sauvegarde qu’on peut réaliser sur une base de données sont :

  1. Sauvegarde de données
  2. Sauvegarde des journaux de transactions
  3. Sauvegarde de type copie seule

 

L’étendu d’une sauvegarde peut être soit une base de données complète, une base de données partielle ou un ensemble de fichiers ou groupes de fichiers. Pour chacun de ces étendues on peut faire soit des sauvegardes complètes soit des sauvegardes différentielles.

Une sauvegarde différentielle dépend de la dernière sauvegarde complète réalisée avant celle-ci, la perte de la sauvegarde complète implique la perte de toutes les sauvegardes différentielles réalisées après.

Chaque sauvegarde de base de données contient la portion du journal de transaction qui permet de remettre la base de données à la fin de l’opération de sauvegarde.

Une sauvegarde de type copie seule (Copy Only) nous permet de réaliser des sauvegardes sans affecter la stratégie de sauvegarde mise en place, ce qui veut dire qu’une sauvegarde en copie seule même si c’est une sauvegarde complète n’affecte pas le chainage entre les sauvegardes différentielles réalisées après celle-ci et la sauvegarde complète normale réalisée avant elle.

Mode de récupération

Si le mode de récupération d’une base de données est Simple, la sauvegarde des journaux de transaction est désactivée pour celle-ci, en effet SQL Server prendra en charge la gestion des fichiers journaux et à chaque point de contrôle les parties inactives du journal seront tronquées.

clip_image002

Le mode de récupération Journalisé en bloc est un mode complémentaire au mode complet qui permet d’optimiser les opérations en bloc mais n’offre pas le même niveau de protection que le mode complet, en effet ce mode ne prend pas en charge la récupération de la base de données à une date et heure précise.

Meilleures pratiques

  • Choisir le mode de récupération Simple pour les bases de données de développement et de test
  • Si votre base de données est configurée avec un mode de récupération complet ou journalisé en bloc il ne faut pas oublier de réaliser des sauvegardes des journaux de transaction.
  • Une sauvegarde différentielle d’une base de données contient toutes les pages de données modifiées depuis la dernière sauvegarde complète, sans la sauvegarde complète de référence une sauvegarde différentielle ne peut pas être restaurée ; dans le cas où on met en place une stratégie de sauvegarde à base de sauvegarde complète et différentielles il faut bien faire attention à ne pas perdre la sauvegarde complète.
  • L’application d’une mise à jour ou d’un patch de sécurité qui change le numéro de version de votre serveur SQL doit être suivi immédiatement d’une sauvegarde des bases de données système, en fait les anciennes sauvegardes seront obsolètes dans ce cas.

SQL Server 2008 : Meilleures Pratiques pour le stockage

L’optimisation des performances des serveurs SQL Server passe obligatoirement par la mise en place d’une infrastructure de stockage adéquate. Les consignes suivantes permettent d’améliorer les performances de vos serveurs de bases de données SQL Server.

  1. Placer les fichiers de données, les fichiers journaux et la base de données TempDB sur des disques dédiés
  2. Aligner les partitions de vos disques (Windows Server 2003 et antérieurs)
  3. Aligner le nombre de fichiers de données de vos bases de données et principalement la base de données TempDB au nombre de processeurs du serveur.
  4. Formater les disques qui hébergent les fichiers de données avec une taille de cluster adéquate (8, 16, 32 ou 64 Ko), le choix de la taille doit se faire suite à une analyse et des tests qui prendront en compte le contexte d’exploitation de votre base de données et les caractéristiques techniques de votre équipement de stockage.
  5. Favoriser les systèmes RAID 1+0 pour les disques qui hébergeront les journaux de transaction et la base de données TempDB
  6. Planifier convenablement la taille des fichiers de données, des fichiers journaux ainsi que la taille des fichiers de la base de données TempDB.