Objectif : générer, au travers d’un mapping PowerCenter, plusieurs fichiers de sortie qui ont pour nom la valeur contenue dans un fichier en entrée.

Exemple :

Construction du mapping : le mapping doit contenir au minimum les objets suivants :

• Un objet « Source » : permet la définition des données en entrée.
• Un objet « Expression Definition » : permet la définition de variables nécessaire au split des données en entrée.
• Un objet « Transaction Control Transformation » : permet la génération des différents fichiers de sortie.
• Un objet « Target » : permet la définition des fichiers de sortie.

Définition des objets :

• L’objet « Source » : dans cet exemple, il est supposé que le nom des différents fichiers de sortie est situé en début de ligne (colonne NOM_FIC).

Il est également supposé que cette colonne est séparée du reste de la ligne par un caractère présent une seule fois par enregistrement.

• L’objet « Expression Definition » : Dans l’exemple suivant, l’objet contient :

En entrée :

• • NOM_FIC : contient le nom des fichiers de sortie tel que donné par le fichier source
  • RESTE_LIGNE : contient le reste de l’enregistrement
  En intermédiaire :
  • Curr_Name : permet de stocker le nom de fichier de l’enregistrement précédent.

En sortie :

• • NOM_FIC_OUT : contient le nom complet des fichiers de sortie (répertoire + nom du fichier)
  • RESTE_OUT : contient le reste de l’enregistrement avec suppression des espaces en fin d’enregistrement.
  • Prev1_Out : contient le calcul de la variable Curr_Name
  • Prev2_Out : contient le nom du fichier de sortie tel que donné en entrée

• L’objet « Transaction Control Transformation » :

C’est dans cet objet que se réalise la génération des multiples fichiers de sortie. Dans l’onglet « Properties », il faut renseigner l’attribut « Transaction Control Condition ». Dans le cas où le nom de fichier courant est différent du nom de fichier de l’enregistrement précédent, il faut signifier la rupture avec la commande TC_COMMIT_BEFORE. Dans le cas contraire, il faut utiliser la commande TC_CONTINUE_TRANSACTION pour stocker les enregistrements jsqu’à la prochaine rupture.

N.B. : pour optimiser les performances et minimiser la log, il faut avoir en entrée un fichier trié sur le nom de fichier.

• L’objet « Target » :

Afin de signifier que le nom des fichiers de sortie est passé en paramètre, il faut cliquer sur le bouton « Add Filename column to the folder ». Il faudra renseigner le nouveau champ « FileName » avec la variable en sortie du « Transaction Control Transformation » qui contient le nom des fichiers.

Aucune particularité n’est nécessaire en ce qui concerne la configuration de le Session.

 

1. Introduction

L’objectif de cet article est de vous aidez à configurer votre poste 64 bits pour travailler avec des connexions Oracle client en utilisant SSIS.

2. Installation

Pour commencer nous allons installer la version cliente 32 bits d’oracle. Nous utiliserons comme exemple, la version d’oracle 11.2.0

2.1. Installation Oracle 32 bits.

Choisissez Exécution comme type d’installation, ceci vous permets de notamment de bénéficier d’outil comme sql developper (pour se connecter sur des BDD oracle, faire des requêtes sql etc…)

Après avoir choisi vos langues, choisissez le répertoire où sera installé Oracle. Si vous êtes plusieurs à travailler sur ce poste, je vous conseil de choisir d’installer la version cliente sur un répertoire racine (C : ou D :..)

Pour le reste, faites Suivant jusqu’à la fin de l’installation.

2.2. Installation Oracle 64 bits.

Pour l’installation de la version 64 bits procédez de la même façon que la version 32 bits. Choisissez à nouveau un répertoire à la racine de préférence.

Faites Suivant jusqu’à la fin de l’installation.

3. Configuration des providers Oracle

Vous devez modifier des valeurs de clé de registre, afin de bénéficier des providers Oracle avec SSIS.

3.1. Configuration 32 bits

Connectez vous à la base de registre (tapez la commande regedit dans exécuter). Dans le registre HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSDTC\MTxOCI, modifiez les clés suivantes :

• OracleOciLib = oci.dll
• OracleSqlLib = orasql11.dll   (old: SQLLib80.dll) 
• OracleXaLib = oraclient11.dll  (old: xa80.dll) 

3.2. Configuration 64 bits

Dans le registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI, modifiez les clés suivantes :

• OracleOciLib = oci.dll
• OracleSqlLib = orasql11.dll   (old: SQLLib80.dll) 
• OracleXaLib = oraclient11.dll  (old: xa80.dll) 

Vous devez rebooter la machine.

 

4. Créer votre connexion Oracle dans le TNSNAME

Pour créer votre connexion Oracle vous avez 2 solutions soit vous passez par l’interface d’oracle comme ci-dessous, soit vous allez directement la configurer dans le fichier TNSNAME avec Notepad.

le TNSNAME est dans le répertoire suivant %ORACLE_HOME%/network/ADMIN/ (emplacement du logiciel que vous avez choisi pendant l’installation). Vous devez le configurer dans le répertoire 32 bits et 64 bits

Pour vérifier si votre connexion est valide, ouvrez un éditeur de commande et tapez la commande tnsping
NonDuServiceOracle

Cette commande permet de vérifier que votre service Oracle répond à travers le réseau.

5. Configuration de SSIS

Vous pouvez à présent, utiliser votre connexion cliente Oracle avec SSIS. Dans votre projet SSIS, choisissez une connexion OLEDB de type OLEDB for Oracle Provider. Il y a deux choses importantes à paramétrer. La solution du projet en mode 32 bits et le connecteur OLEDB.

5.1. Forcer la solution du projet SSIS à travailler en 32 bits

Sachez que les providers OLEDB pour Oracle sur les plateformes Microsoft marchent qu’en 32 bits. Dans les propriétés de la solution SSIS changer l’option suivante :

5.2. Modifier la propriété UseDefaultCodePage du connecteur OLEDB

Pour éviter un warning au niveau du connecteur OLEDB modifier la propriété suivante :

 

 

Voilà vous pouvez extraire vos données.

FIN

 

 

Lorsque l’on veut démarrer un job sur sql server agent, il n’est pas forcément nécessaire d’utiliser l’interface sql server management studio. Vous pouvez piloter vos jobs, soit en créant une interface maison (une web part par exemple) ou directement par sql. Je vous propose de vous décrire les étapes les plus utilisées.

1. Récupération de liste des jobs et leurs statuts

Pour récupérer la liste des jobs, je vous conseille de faire appel a la procédure stockée suivante msdb.dbo.sp_help_job . Cette procédure ramène les informations complètes sur les jobs y compris le statut en cours.

On va s’intéresser à 2 champs :

• job_id : identifiant du job nécessaire pour accéder à l’historique des jobs.
  
• Current_execution_status : spécifie le statut en cours du job.
  

  Définition de la liste des statuts :
  0 = arrêté ou suspendu,
  1 = en cours d’exécution,
  2 = en attente d’un thread,
  3 = réessaie,
  4 = arrêté,
  5 = suspendu,
  6 = en attente de terminaison d’étape,
  7 = exécutions des actions d’achèvement
  

2. Démarrage et arrêt d’un job

2.1 Démarrage du job

Pour démarrer un Job sans passé par l’interface de sql server agent, il suffit de faire appel à la procédure stockée msdb.dbo.sp_start_job .Cette procédure nécessite en paramètre le nom du job à exécuter. Comme dans l’exemple ci-dessous :

Exec msdb.dbo.sp_start_job
‘My_Job_Name’

2.2 Arrêt du job

Pour stopper un Job sans passé par l’interface de sql server agent, il suffit de faire appel à la procédure stockée msdb.dbo.sp_stop_job . Cette procédure nécessite également en paramètre le nom du job à exécuter. Comme dans l’exemple ci-dessous :

Exec msdb.dbo.sp_stop_job
‘My_Job_Name’

3. Connaître le résultat de l’exécution d’un job

Avec la table sysjobhistory il est possible de savoir si l’exécution d’un job c’est terminé avec succès ou non. Après avoir récupérer au préalable l’ID du job, il vous suffit de récupérer la dernière instance, est lire la colonne run_status pour connaître le résultat de l’exécution.

SELECT [instance_id] ,[step_id],[run_status] FROM [msdb].[dbo].[sysjobhistory] where [job_id]= ‘JobID’
and [instance_id] in
(select
Max([instance_id]) FROM [msdb].[dbo].[sysjobhistory] where [job_id] =
‘JobID’)

L’idée est de montrer comment créer une table SQL qui enregistre les logs d’une instance Analysis Services.

Ces logs permettront par la suite d’extraire des informations tel que :

• Le nombre d’utilisateurs uniques d’un cube
• Le nombre de sessions uniques

Ces mesures pourront alors être analysée et suivie par date et par heure.

Configurer l’instance Analysis Services

La configuration par défaut :

• Au niveau du paramètre Log\QueryLog\QueryLogConnectionString et de la colonne Value, cliquez sur l’icône de sélection :

• Enfin passez le paramètre Log\QueryLog\CreateQueryLogTable à True :

• Puis validez en cliquant sur le bouton OK.

La table a alors été créé dans la base de données cible précédemment sélectionnée :

Après quelques requêtes sur le cube, la table se peuple ainsi :

SELECT
TOP 1000 [MSOLAP_Database]

,[MSOLAP_ObjectPath]

,[MSOLAP_User]

,[Dataset]

,[StartTime]

,[Duration]

FROM [Audit].[dbo].[OlapQueryLog]

L’option QueryLogSampling

L’option Log\QueryLog\QueryLogSampling permet de spécifier la fréquence de l’échantillon des requêtes remontées dans la table de logs.

Une valeur à 10, signifie qu’une requête sur 10 serait remontée dans la table de logs.

Si vous souhaitez capturer toutes les logs, il vous faudra donc passer cette valeur à 1 :

Bien entendu, une valeur de 1 peut occasionner de la charge sur votre serveur de base de données.

Requêtes types

Récupération d’information sur l’utilisation du cube ces dernières 24 heures :

– Nb d’utilisateurs uniques

SELECT
COUNT
(DISTINCT [MSOLAP_User] )

FROM [dbo].[OlapQueryLog]

WHERE [StartTime] >=
DATEADD(DAY,
-1, GETDATE())

– Nb de requêtes executées

SELECT
COUNT(*)

FROM [dbo].[OlapQueryLog]

WHERE [StartTime] >=
DATEADD(DAY,
-1, GETDATE())

– Cout des requêtes executées

SELECT
SUM(Duration)

FROM [dbo].[OlapQueryLog]

WHERE [StartTime] >=
DATEADD(DAY,
-1, GETDATE())

– Liste des utilisateurs d’une base de données

SELECT MSOLAP_Database, MSOLAP_User, StartTime, Duration,

CAST(CONVERT(varchar(8), StartTime, 112) AS
int) AS
Day

FROM OlapQueryLog

WHERE (MSOLAP_Database =
‘DataWarehouse’)
and [StartTime] >=
DATEADD(DAY,
-30, GETDATE())

ORDER
BY StartTime DESC

– Liste des utilisateurs par base de données et par jour

SELECT MSOLAP_Database, MSOLAP_User,
SUM(Duration)
AS Duration,

CAST(CONVERT(varchar(8), StartTime, 112) AS
int) AS Day_FK, COUNT(*)
AS QueryCount

FROM OlapQueryLog

GROUP
BY MSOLAP_Database, MSOLAP_User,
CAST(CONVERT(varchar(8), StartTime, 112) AS
int)

ORDER
BY Day_FK

Exemple de rapports et d’indicateurs

La table de log, vous permettra ainsi d’alimenter certains indicateurs de votre tableau de bord d’exploitation :

De pouvoir suivre l’évolution du nombre d’utilisateurs consommateurs de vos cubes au quotidien :

Et bien entendu d’en avoir la liste :

Le décisionnel Microsoft s’oriente vers le BISM (Business Intelligence Semantic Model) en fusionnant le modèle de PowerPivot et celui, plus classique, d’ Analyses Services (UDM). C’est dans ce contexte que l’on trouve une des grandes nouveautés de powerPivot : la vue diagramme ! bien plus pratique pour réaliser nos modèles d’analyse.

Retour vers la synthèse des nouveautés de Powerpivot V2.

D’autres articles à venir sur les autres nouveautés…

Je vous propose ici un retour d’expérience sur l’optimisation de procédures stockées SQL server. Cette optimisation est issue de recherche effectuée pour analyser des problèmes de lenteur sur des rapports Reporting Services utilisant des procédures stockées avec passage de paramètres.

Le cas m’est apparu en constatant que les temps d’exécution d’une même requête SQL pouvaient varier de 8s à plus de 10mn selon que je l’exécutais directement dans l’éditeur management Studio ou incorporée à une procédure stockée.

Ce problème est appelé « parameter sniffing ou spoofing». En synthèse, le moteur SQL Server essaye d’optimiser la requête en définissant un plan d’exécution basé sur les statistiques. Ces dernières sont établies lors de la première exécution de la requête et sont donc dépendantes de la valeur du paramètre utilisée pour cette exécution.

Ce plan d’exécution pose problème dès que la distribution des données est biaisée : certains paramètres vont retourner un petit nombre de lignes tandis que d’autres vont au contraire en renvoyer un grand nombre.

Le plan d’exécution n’étant pas recalculé à chaque fois, les temps ne sont plus optimisés.

Ci-dessous un exemple (source http://blogs.msdn.com/b/queryoptteam/archive/2006/03/31/565991.aspx) afin d’expliquer avec plus de détails les points précédents :

Soit les objets suivants :

Une table t de 1002000 lignes avec 100000 lignes allant de 1 à 999999 et 2000 autres lignes avec la valeur 1000008.

	Col1
1	1
2	2
…	…
1000000	999999
1000001	1000008
…	1000008
1002000	1000008

Soit la procédure stockée ci-joint interrogeant la table t.

Une première analyse du plan d’exécution de la procédure stockée avec le paramètre ‘450’ nous donne les informations suivantes :

Il est estimé que le nombre de ligne est de 1 et le nombre de ligne renvoyé est aussi de 1.

Dans la deuxième exécution nous allons mettre le paramètre suivant : ‘1000008’ (qui représente 2000 lignes dans la base de données) et nous allons observer le plan d’exécution :

Le plan d’exécution estime que le nombre de lignes renvoyées est de 1 alors que le nombre de lignes retournées réellement est de 2000.

Ce plan d’exécution n’est pas optimisé pour le paramètre d’une valeur de ‘10000008’.

En effet le précédent paramètre fourni, d’une valeur de ‘450’, a été aspiré par l’optimiseur SQL et gardé en mémoire ; d’où la mauvaise estimation.

Pour remédier à ce problème et ainsi obtenir de meilleures performances, plusieurs solutions existent : la déclaration d’un paramètre en local (ainsi le paramètre ne peut être aspiré par l’optimiseur de requête SQL) ou l’ajout d’une option ‘‘recompile’’.

Exemple :

Dans le premier cas en déclarant une variable locale, le nombre estimé passe à 1,11332 lignes, qui correspondent au calcul suivant : [1/1000001 (nombre de valeur distinct)]*1002000(nombre total de lignes).

Cette première solution utilise les statistiques de la table pour estimer le nombre de lignes. Elle présente cependant un inconvénient quand les données ne sont pas réparties équitablement.

Dans le deuxième cas, en utilisant l’option recompile, nous forçons le moteur à recompiler la requête SQL, ce qui peut être contraignant en terme de temps processeur si celle-ci est complexe, mais le plan d’exécution obtenu est toujours optimisé pour le paramètre aspiré.

Dans notre cas l’estimation du nombre de lignes correspond au résultat attendu.

Bilan en termes de performances :

	Défaut	Variable locale	Option recompile
@p=5	91 ms	89 ms	87 ms
@p=1000008	288 ms	255 ms	166 ms

Ci-dessus les temps écoulés lors de l’exécution de la procédure stockée. Dans le cas par défaut le paramètre @p=5 a été aspiré, ce qui induit un temps d’exécution de 288 ms pour le paramètre @p=1000008.

En comparaison, le fait de déclarer une variable locale ou de mettre en place une option recompile ne change pas les temps de traitement pour le paramètre @p=5, les nombres de lignes estimés étant proches, les temps sont quasi-identiques. Cependant, une différence est notable avec le paramètre @p=1000008 : avec l’option recompile, la procédure stockée possède un plan d’exécution optimisé, d’où une meilleur performance. Dans le cas de la déclaration en locale d’une variable avec @p=1000008, le plan étant optimisé à l’aide des statistiques (estimation de 1,1 lignes par résultat) le temps d’exécution reste important face à l’option recompile mais préférable à celui par défaut.

En conclusion, en fonction des cas de figure rencontrés (données biaisées, procédure stockée complexe …), il est préférable d’utiliser l’une des solutions proposées.

Il peut être parfois utile d’exécuter une requête MDX directement depuis Excel. Ainsi, on ne s’encombre pas de toutes les dimensions / mesures du cube, et ainsi, on exécute la requête beaucoup plus rapidement.
On peut ainsi utiliser directement un tableau croisé dynamique que l’on mettre à jour régulièrement, afin d’avoir une information toujours à jour.

La méthode est simple : utiliser un fichier datasource (.odc) personnalisé avec sa requête MDX

Pour cela :

1. Téléchargez ce fichier, et enregistrez-le dans le dossier ‘Mes Data Sources’ du dossier Mes documents.

2. Ouvrez-le avec un éditeur de texte classique, et modifiez les lignes suivantes :

• ligne 8 <title>Detail_Forecast all regions</title> : remplacez par un titre approprié
• ligne 12 <o:Name>Detail_Forecast all regions</o:Name> : remplacez par un titre approprié. Attention, c’est le nom qui apparaîtra sous Excel dans la liste des connexions.
• ligne 18 <odc:ConnectionString>Provider=MSOLAP.3;Integrated Security=SSPI;Persist Security Info=True;Initial Catalog=<Nom_de_la_base_OLAP>;Data Source=<Serveur_OLAP>;MDX Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error</odc:ConnectionString> : remplacez par la datasource voulue (que l’on trouve généralement dans un ficher de cube Excel), ou remplacez celle-ci par les valeurs appropriées.
• ligne 20 <odc:CommandText>Insérer la requête MDX ici</odc:CommandText> : C’est ici que vous allez insérer la requête MDX. Attention de ne pas faire apparaître de paramètres (@Parameter, CONSTRAINED) car Excel ne les supporte pas.

3. Enregistrez le fichier.

4. Ouvrez Excel, et aller sur l’onglet ‘Données’.

5. Cliquez sur ‘Connexions existantes’ et sélectionnez votre fichier datasource précédemment enregistré

6. Une fois ouvert, le résultat de la requête s’affichera sous forme de table. Si vous souhaitez plutôt l’utiliser sous forme de Pivot, à l’étape 4, allez à l’onglet ‘Insertion’, puis sélectionnez ‘TblCroiséDynamique’, et choisissez le fichier datasource.

Pouvoir être en mesure de suivre la bonne exécution des traitements batch SSIS est primordiale.

Plusieurs solutions permettent de répondre à ce besoin de suivi :

1. La méthode manuelle : Management Studio propose un historique d’exécution des jobs
2. L’utilisation de tâches SQL permettant de renseigner une table de log
3. L’utilisation des logs standards SSIS

La solution 2. est très souvent rencontrée sur les projets par simple méconnaissance de la 3.

Cet article décrit donc comment mettre en place en quelques minutes un suivi des traitements SSIS performant.

L’activation des logs s’effectue pour chaque package dans le menu SSIS\Enregistrement (Logging en version anglaise)

Les étapes à réaliser sont les suivantes :

1. Choisir dans la liste déroulante type de fournisseur, où seront stockés les logs (base de données, fichier XML,…) puis cliquer sur le bouton Ajouter. Personnellement, je préconise le stockage SQL Server qui permet une exploitation aisée de ces données
2. Cocher la case à cocher devant le nom du package
3. Activer la case à cocher devant le fournisseur SQL Server
4. Sélectionner la base de données hébergeant la table de log

Remarque : Il n’est pas possible de choisir le nom de la table dans laquelle les logs seront stockés. SSIS 2005 les stocke dans la table sysdtslog90, SSIS 2008 dans sysssislog.

L’onglet Détails permet ensuite de spécifier le niveau de finesse dans le suivi des traitements :

Afin d’éviter des logs trop volumineux, je recommande de tracer uniquement les événements suivants :

• OnPreExecute : Trace le début d’exécution des différentes tâches présentes dans le niveau Flux de Contrôle
• OnPostExecute : Trace la fin d’exécution des différentes tâches présentes dans le niveau Flux de Contrôle
• OnError : Trace toutes les erreurs survenues aux niveaux Flux de contrôle et Flux de données

Les principaux champs de la table de logs sont les suivants :

• Event : événement qui a généré le log (OnPreExecute, OnPostExecute ou OnError)
• Computer : ordinateur qui l’a exécuté
• Operator : utilisateur qui l’a exécuté (permet par exemple de différencier une exécution automatique effectuée par l’agent SQL Server d’une exécution manuelle de rattrapage)
• Source : étape du flux qui a généré le log
• SourceId : Identifiant de l’élément (package, tâche de contrôle…) ayant généré le log
• executionId : identifiant unique de l’exécution
• Starttime : début de l’événement qui a généré le log
• Endtime : fin de l’événement qui a généré le log
• Message : détails de l’événement (notamment les messages d’erreurs sur l’événement OnError)

En quelques clics nous avons ainsi paramétré le stockage de l’information relative à l’exécution des flux SSIS. Ces données peuvent maintenant être requêtées en SQL ou utilisées via du reporting.

A noter qu’une ligne est écrite dans la table de log pour chaque événement: début d’une tâche, fin d’une tâche ou erreur. Les données doivent donc être manipulées pour obtenir une ligne du type: nom de la tâche, date de début, date de fin et statut d’exécution.

Homsys propose ainsi un ensemble de tableaux de suivi développés sous Reporting Services. Cet aspect sera présenté dans un prochain article…

Fonctionnalité souvent méconnue et sous utilisée : SSIS (SQL Server Integration Services) permet de créer des modèles de package qui intègrent les éléments récurrents d’un projet.

Pourquoi utiliser des modèles de package :

Un modèle de package pourra par exemple contenir les éléments suivants :

• Cartouche d’en tête documentant le flux (description du flux, date de création, auteur…)
• Activation des logs d’audit des traitements
• Connexion vers les bases de données du projet
• Variables communes (nom du serveur DWH, chemin de stockage des fichiers sources, chemin de l’archivage…)
• Utilisation du fichier de configuration qui permet l’alimentation dynamique des variables communes
• Propriété delayValidation valant True afin d’éviter les ralentissements à l’ouverture des packages

La mise en place de ces éléments permet ainsi un gain de temps intéressant, une homogénéisation des différents développements (les variables communes auront le même nom dans l’ensemble des packages) ainsi qu’un risque d’anomalie réduit (erreur de paramétrage des connexions, du fichier de configuration…).

Comment développer un package modèle ?

Un package modèle est un package SSIS standard dans lequel les éléments communs auront été implémentés. Ce package doit ensuite être copié dans le répertoire :

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems

Comment utiliser un package modèle :

L’utilisation du modèle de package s’effectue via les étapes suivantes :

Cliquer droit sur le projet puis Ajouter\Nouvel Element :

Utiliser un modèle de package Etape 1

Ajouter l’élément Package_model_SSIS :

Utiliser un modèle de package Etape 2

Que ce soit pour tester un nouvel outil, pour valider une architecture ou pour monter un environnement de formation, nous sommes tous régulièrement amenés à utiliser des machines virtuelles ou VM.

Ayant récemment été confronté à certaines difficultés pour « monter » une VM en 64 bits sous notre serveur VMware, voici un billet détaillant la procédure à suivre.

OS 64 bits supportés par VMware

En premier lieu, voici une petite liste (non exhaustive) des systèmes d’exploitations 64-bits supportés par VMware :

• Windows XP 64-bit
• Windows Vista 64-bit
• Windows 2003 Server 64-bit
• Windows 2008 Server 64-bit
• Linux 64-bit
• Applications entreprises en 64-bit, comme Exchange 2007 64-bit
• …

Tester la capacité du serveur hôte

Une chose à savoir concernant la capacité de son serveur de VM (host server) à exécuter des VM 64-bits : le serveur hôte doit obligatoirement être en 64-bits.  Il n’est pas possible d’exécuter  une machine virtuelle 64 bits sur un serveur 32 bits.

Enfin tous les serveurs 64 bits ne sont pas forcément aptes à lancer des VM en 64 bits. Cela dépend aussi du processeur.

Heureusement l’éditeur a mis en place un outil qui effectue cette vérification :

• c’est le Processor Check for 64-bit Compatibility qui est téléchargeable à l’adresse suivante :  http://downloads.vmware.com/d/info/datacenter_downloads/vmware_server/2_0#drivers_tools

Configurer le serveur de VM

Une fois avoir vérifier la capacité du serveur hôte il faut éditer les propriétés du BIOS de celui-ci :

1. Démarrer le serveur
2. Taper F2 afin de lancer le ‘System Setup’ du serveur
3. Entrer dans  « CPU Information »
4. Activer l’option « Virtualization Technology » (VT) qui est désactivée par défaut
5. Redémarrer le serveur

=> Le serveur hôte est maintenant prêt à accueillir des VM 64 bits

Créer la machine virtuelle

La création de la VM 64-bits se fait ensuite très simplement en sélectionnant un OS 64-bits (voir copie d’acran ci-dessous).

Sources

Remerciements à Olivier Marché pour son expertise technique sur la question.

Liens sur VMware et le 64-bits :

http://www.petri.co.il/virtual_run_a_64_bit_guest_operating_system_in_vmware.htm

http://communities.vmware.com/message/1174789

Lien sur l’édition des propriétés du BIOS :

http://support.euro.dell.com/support/edocs/systems/pe1900/en/hom/html/syssetup.htm#wp1054756