Dans cette section, vous découvrirez comment créer des classes de gestion et de stockage VTCS et comment effectuer les tâches courantes qui leur sont associées.
Un aspect important des solutions de pointe consiste à connaître le niveau de CDS du VTCS, ainsi que ce qu'il peut ou ne peut pas accomplir. Le Tableau 6-1 décrit les niveaux CDS est les fonctions qu'ils prennent en charge.
Tableau 6-1 Niveaux de CDS pour les versions du VTCS prises en charge
| Niveau de CDS du VTCS : | Versions du VTCS/NCS : | Améliorations : |
|---|---|---|
|
E |
6.0, 6.1, 6.2, 7.0 |
|
|
F |
6.1, 6.2, 7.0, 7.1, 7.2, 7.3 |
|
|
G |
6.2, 7.0, 7.1, 7.2, 7.3 |
|
|
H |
7.1, 7.2, 7.3 |
|
|
I |
7.3 |
|
Les classes de gestion et de stockage VTCS, qui sont les piliers de nombreuses infrastructures de pointe, remplissent les fonctions suivantes :
Les classes de gestion VTCS spécifient comment le VTCS gère les VTV. L'instruction de contrôle MGMTclas de HSC définit une classe de gestion et ses attributs. Par exemple, le paramètre DELSCR de l'instruction MGMTclas spécifie si le VTCS supprime les volumes VTV provisoires du VTSS.
Les classes de gestion peuvent également pointer vers des classes de stockage VTCS. Les classes de stockage VTCS indiquent où résident les VTV migrés. L'instruction de contrôle STORclas de HSC définit une classe de stockage et ses attributs. Par exemple :
MGMT NAME(PAYROLL) MIGPOL(LOCAC,REMAC) STORCLAS NAME(LOCAC) ACS(00) MEDIA(STK1R) STORCLAS NAME(REMAC) ACS(01) MEDIA(STK2P,ZCART)
Cette combinaison de classes de gestion et de stockage indique "For Management Class PAYROLL, migrate duplexed to separate MVCs in the local and remote ACSs. Dans l'ACS local, placez le média 9840 afin de pouvoir y accéder rapidement en cas de nécessité. Dans l'ACS distant, préférer le média 9940 au média ZCART, mais les y placer absolument dans un stockage profond.
Commencez par "Création et utilisation des classes de gestion et de stockage VTCS : Principes fondamentaux", qui est une procédure élémentaire que vous pouvez adapter selon vos besoins professionnels. Passez ensuite à la section "Techniques de pointe que vous pouvez mettre en oeuvre grâce aux classes de gestion et de stockage". Envisagez cette section comme une galerie où vous pouvez voir diverses options, puis choisir celle qui vous convient le mieux.
Dans la mesure où vous rencontrerez souvent ce motif (TAPEREQ > POLICY > MGMTclas > STORclas), nous vous invitons à vous familiariser avec celui-ci, car il s'agit de la base de toutes les informations présentées à la section "Techniques de pointe que vous pouvez mettre en oeuvre grâce aux classes de gestion et de stockage."
Déterminez le jeu de données de définition contenant les instructions STORclas et MGMTclas.
Les instructions MGMTclas et STORclas doivent résider dans le même jeu de données pour la validation croisée.
Définissez des classes de stockage par le biais de l'instruction de contrôle STORclas.
Ajustez les stratégies de migration comme vous le souhaitez à l'aide des commandes MIGRSEL et MIGRVTV.
Définissez des classes de gestion à l'aide de l'instruction de contrôle MGMTclas.
Notez que l'instruction de contrôle MGMTclas spécifie les classes de stockage dans divers paramètres.
Chargez les instructions de contrôle avec la commande HSC MGMTDEF.
Spécifiez une stratégie de bande dans la commande SMC POLICY.
Renseignez le nom de la stratégie par VTCS dans l'un ou l'autre des éléments suivants :
Instruction SMC TAPEREQ.
Routines SMS que vous écrivez dans l'interface StorageTek DFSMS.
Prenez en compte les points suivants :
Utilisez toujours la commande SMC POLICY pour affecter la classe de gestion à des montages.
Vous pouvez spécifier une stratégie à l'aide de l'instruction TAPEREQ ou des routines SMS.
Utilisez POLICY VALIDATE pour vous assurer que vos instructions SMC POLICY font toutes référence aux noms VALID MGMTCLAS.
Vous pouvez utiliser l'utilitaire VTVMAINT pour modifier la classe de gestion d'un VTV. Notez également que, bien que vous ne puissiez pas utiliser VTVMAINT pour modifier directement la classe de stockage d'un VTV, vous pouvez l'utiliser pour modifier la classe de gestion d'un VTV, laquelle peut faire référence à une classe de stockage différente.
Utilisez uniquement le nombre minimum de classes de stockage requis pour définir les stratégies que vous souhaitez implémenter. Un nombre excessif de classes de stockage peut affecter les performances du VSM en raison des charges supplémentaires qu'impliquent le montage/démontage des MVC. En outre, une MVC peut uniquement contenir des VTV dans une classe de stockage unique. Par conséquent, un nombre excessif de classes de stockage peut entraîner une sous-utilisation de l'espace MVC.
Si vous décidez de supprimer une définition de classe de gestion, exécutez un rapport VTV pour vous assurer que la classe de gestion n'est plus affectée à aucun VTV, sinon vous risquez d'obtenir des résultats imprévisibles !
La liste suivante n'est pas exhaustive mais elle présente quelques-unes des tâches les plus courantes que vous pouvez effectuer avec les classes de gestion et de stockage :
Utilisation du paramètre STORclas MEDIA pour définir les préférences de médias MVC. Des préférences de médias MVC par défaut sont définies, mais vous pouvez les ajuster à votre convenance. Pour plus d'informations, reportez-vous à Gestion du HSC et du VTCS.
"Regroupement de plusieurs charges de travail sur des MVC partagées". Cet exemple nous a servi d'introduction et est particulièrement utile si votre entreprise possède le centre de données et vous voulez optimiser l'utilisation de vos ressources disponibles en :
Mettant en duplex les données critiques sur des MVC distinctes dans les ACS local et distant. Dans l'ACS local, placez le média 9840 afin de pouvoir y accéder rapidement en cas de nécessité. Dans l'ACS distant, préférez le média 9940 au média ZCART pour un stockage profond sur un média haute capacité.
En fournissant l'accès à deux flux de tâches critiques (paie et comptabilité) à ces classes de gestion/stockage. Résultat : toutes vos données de paie et de comptabilité sont mises en duplex aux niveaux local et distant et sont regroupées dans le même jeu de MVC des médias appropriés, traités dans les spécifications des classes de stockage.
Les données de production sont également critiques, mais vous souhaitez qu'elles résident sur un jeu de MVC distinct de ceux qui sont utilisés pour les données de paie et de comptabilité. Cela peut se faire sans difficulté. Il vous suffit juste de créer une autre combinaison de classes de gestion/stockage pour les données de production.
"Ségrégation de charges de travail individuelles dans des jeux de MVC séparés". Tous vos groupes d'intervention analysent ces données attentivement, car vous les utiliserez probablement beaucoup. Avez-vous jamais voulu offrir à chacun de vos clients son propre jeu de ressources pour la facturation/sécurité ? La ségrégation des charges de travail est la clé.
"Archivage des données". Dans ce scénario, vous pouvez utiliser le VTCS pour imiter le HSM dans l'environnement de bande automatisée/bande virtuelle StorageTek uniquement. En d'autres termes, vous pouvez utiliser les paramètres ARCHAge et ARCHPol de l'instruction MGMTclas pour définir une stratégie d'archivage pour les VTV dans une classe de gestion.
La gestion du cycle de vie des informations (ILM, Information Lifecycle Management), stratégie de gestion du stockage StorageTek, repose sur l'idée que les données doivent être stockées sur des médias correspondant à leur importance pour l'entreprise et leur schéma de réutilisation. Les données importantes et dynamiques sont placées sur des médias à accès rapide et sont dupliquées en plusieurs copies, tandis que les données moins importantes et peu dynamiques sont archivées sur des médias haute capacité moins coûteux. L'automatisation de ce processus est le moyen le plus rentable de gérer le stockage des données. L'archivage met en oeuvre la stratégie ILM en vous permettant d'archiver les données peu dynamiques. Grâce à l'archivage VTCS, vous pouvez déplacer les VTV vers différents médias (par exemple, d'un média 9840 à accès rapide vers un média 9940 haute capacité) et à un emplacement différent (par exemple, d'un ACS local vers un ACS distant pour éjection/archivage sécurisé). Pour plus d'informations, reportez-vous à la section "Archivage des données".
"Rapprochement des médias et de l'emplacement des VTV". Envisagez l'archivage comme une opération proactive. Vous placez les données sur le média approprié au début du cycle ILM, puis vous les déplacez vers un autre média au fur et à mesure qu'elles deviennent anciennes. Que se passe-t-il si les données finissent sur un média inapproprié ? Réponse : utilisez l'utilitaire RECONcil pour les déplacer d'une classe de stockage vers une autre.
Contrôle de la migration des VTV. ELS permet de contrôler de très près la migration des VTV, notamment la suppression des VTV provisoires du tampon VTSS, en spécifiant le délai de migration immédiat et le délai de résidence maximal des VTV. Pour plus d'informations, reportez-vous à Configuration du HSC et du VTCS et au manuel Guide de récupération après sinistre et de gestion des données hors site d'ELS.
Vous pouvez utiliser des classes de stockage et de gestion pour regrouper plusieurs charges de travail sur un jeu de MVC partagées. Par exemple, les instructions STORclas ci-dessous définissent les classes de stockage LOC1, LOC2, REM1 et REM2.
STORCLAS NAME(LOC1) ACS(00) MEDIA(STK1R) STORCLAS NAME(LOC2) ACS(00) MEDIA(STK1R) STORCLAS NAME(REM1) ACS(01) MEDIA(STK2P,ZCART) STORCLAS NAME(REM2) ACS(01) MEDIA(STK2P,ZCART)
Les classes de gestion PAY et ACCOUNT spécifient toutes deux les classes de stockage LOC1 et REM1 dans le paramètre MIGPOL. En conséquence, les VTV dans PAY et ACCOUNT sont mis en duplex et regroupés sur les MVC définies par les classes de stockage LOC1 et REM1.
La classe de gestion PROD spécifie les classes de stockage LOC2 et REM2 dans le paramètre MIGPOL. En conséquence, les VTV dans PROD sont mis en duplex et regroupés sur les MVC définies par les classes de stockage LOC2 et REM2, qui sont séparées de celles destinées à PAY et ACCOUNT.
MGMT NAME(PAY) MIGPOL(LOC1,REM1) MGMT NAME(ACCOUNT) MIGPOL(LOC1,REM1) MGMT NAME(PROD) MIGPOL(LOC2,REM2)
Les stratégies de bande qui spécifient les médias virtuels et affectent, respectivement, les classes de gestion PAY, ACCOUNT et PROD sont définies ci-dessous.
POLICY NAME (PPAY) MEDIA(VIRTUAL) MGMT(PAY) POLICY NAME (PACCOUNT) MEDIA(VIRTUAL) MGMT(ACCOUNT) POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)
Enfin, cet exemple se compose d'instructions TAPEREQ qui affectent des stratégies de la manière suivante :
La stratégie PPAY est affectée aux jeux de données comportant des qualificatifs de PAYROLL.**.
La stratégie ACCOUNTS est affectée aux jeux de données comportant des qualificatifs de ACCOUNTS.**.
La stratégie PPROD est affectée à tous les autres jeux de données.
TAPEREQ DSN(PAYROLL.**) POLICY(PPAY) TAPEREQ DSN(ACCOUNTS.**) POLICY(PACCOUNT) TAPEREQ DSN(**) MEDIA(VIRTUAL) POLICY(PPROD)
Lorsqu'une MVC est utilisée pour une classe de stockage, elle reste exclusivement affectée à cette classe de stockage tant qu'elle contient des copies actuelles des VTV. Ce regroupement des VTV sur les MVC est conservé y compris après que les MVC ont fait l'objet d'une récupération.
Mise en garde :
Vous ne pouvez pas utiliser la classe de stockage par défaut (nom du dernier VTSS qui a écrit dans la MVC pour une réclamation ou une migration) pour regrouper des charges de travail.Vous pouvez utiliser des classes de stockage et de gestion pour séparer des charges de travail individuelles sur des jeux de MVC distincts. Par exemple, les instructions STORclas ci-dessous définissent les classes de stockage LOC, CUSTA, CUSTB1 et CUSTB2.
STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P)
L'exemple ci-dessous définit les classes de gestion suivantes :
La classe de gestion CUSTA spécifie la classe de stockage CUSTA dans le paramètre MIGPOL. Le VTCS définit en mode simplex les VTV contenus dans ces classes de gestion uniquement dans la classe de stockage CUSTA (médias 9840 dans l'ACS local), car c'est ce que veut ce client.
Le client B souhaite une meilleure protection, à savoir la mise en duplex sur les ACS local et distant. En conséquence, la classe de gestion CUSTB pointe vers les classes de stockage CUSTB1et CUSTB2.
Enfin, l'ACS local/le média 9840 sont juste parfaits pour vos propres données de production. C'est ce à quoi sert la classe de gestion PROD. Il est fort probable aussi que vous configuriez une stratégie d'archivage pour cette classe de gestion (reportez-vous à la section Archivage des données), afin que vous puissiez finalement la déplacer vers un stockage profond.
MGMT NAME(CUSTA) MIGPOL(CUSTA) MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2) MGMT NAME(PROD) MIGPOL(LOC)
Cet exemple définit les stratégies de bande qui spécifient les médias virtuels et affectent, respectivement, les classes de gestion PAY, ACCOUNT et PROD.
POLICY NAME (PCUSTA) MEDIA(VIRTUAL) MGMT(CUSTA) POLICY NAME (PCUSTB) MEDIA(VIRTUAL) MGMT(CUSTB) POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)
Enfin, l'exemple ci-dessous illustre les instructions TAPEREQ et les affectations de stratégie correspondantes :
La stratégie PCUSTA est affectée aux jeux de données comportant HLQ CUSTA.
La stratégie PCUSTB est affectée aux jeux de données comportant HLQ CUSTB.
La stratégie PPROD est affectée à tous les autres jeux de données.
TAPEREQ DSN(CUSTA.**) POLICY(PCUSTA) TAPEREQ DSN(CUSTB.**) POLICY(PCUSTB) TAPEREQ DSN(**) POLICY(PPROD)
Mise en garde :
Vous ne pouvez pas utiliser la classe de stockage par défaut (nom du dernier VTSS qui a écrit dans la MVC pour une récupération ou une migration) pour séparer les charges de travail.Vous pouvez utiliser les paramètres ARCHAge et ARCHPol de l'instruction MGMTclas pour définir une stratégie d'archivage pour les VTV dans une classe de gestion. Quand l'âge du VTV excède la valeur ARCHAge, le VTV peut alors être archivé dans les classes de stockage spécifiées dans le paramètre ARCHPol. L'archivage réel peut s'effectuer de l'une des deux manières suivantes :
Automatiquement la prochaine fois que le VTV est rappelé et remigré.
Sur demande à l'aide de l'utilitaire ARCHIve.
Un "scénario de simulation" illustrant ce cas de figure peut permettre de garantir la conformité. Le fait est que vous avez des données que vous devez conserver pendant 7 ans pour les auditeurs externes, mais vos auditeurs internes peuvent, eux aussi, vouloir y jeter un oeil une fois par an. Voici donc comment pourrait se présenter la solution :
TAPEREQ DSN(COMPLY.**) POLICY(PCOMPLY) POLICY NAME(PCOMPLY) MEDIA(VIRTUAL) MGMT(COMPLY) MGMT NAME(COMPLY) IMMMED(DELETE) MIGPOL(LOC1) - ARCHAGE(365) ARCHPOL(REMDEEP) STOR NAME(LOC1) ACS(00) MEDIA(STK1R) STOR NAME(REMDEEP) ACS(01) MEDIA(STK2P)
Voilà ce qui se passe dans ce scénario :
Toutes les données de conformité sont immédiatement migrées vers l'ACS local et sont regroupées sur le média 9840. Après l'exécution avec succès de la migration, les VTV sont supprimés du VTSS. "L'âge de l'archive" de ces données est de 365 jours, si les auditeurs internes veulent les consulter l'année suivante.
Après cela, les données peuvent être archivées sur (déplacées vers) un média 9940 dans l'ACS distant.
Résultat : conformité garantie, au meilleur coût possible, tout en optimisant les ressources virtuelles.
Comme indiqué ci-dessus, vous avez le choix entre deux méthodes pour utiliser l'archivage réel : vous pouvez attendre jusqu'au rappel et à la migration du VTV, ou vous pouvez archiver le VTV sur demande à l'aide de l'utilitaire ARCHIve. Le problème, si vous choisissez d'attendre la remigration, c'est qu'il est probable que ces données ne soient pas accessibles. Il est donc fort possible que le meilleur moyen d'archiver les VTV consiste à exécuter l'utilitaire ARCHIve de manière régulière ou selon vos besoins.
Voici quelques conseils relatifs à l'utilisation de l'utilitaire ARCHive :
Pour sélectionner les VTV à archiver, vous pouvez spécifier l'un des paramètres suivants :
MGMTclas pour archiver les VTV dans les classes de stockage spécifiées par le paramètre ARCHAge/ARCHPol des classes de gestion indiquées.
VTV pour archiver une liste ou une plage de VTV pour les classes de gestion correspondantes.
Remarque :
Si vous ne spécifiez pas de valeur pour MGMTclas ou VTV, le VTCS analyse tous les VTV. Il est probable que vous utilisiez la classe de gestion, mais il peut parfois être préférable d'utiliser le volser VTV ou tous les VTV.Si vous ne définissez pas le paramètre MOVEVTV, vous pouvez obtenir un rapport (uniquement) qui offre un "scénario de simulation" utile pour déterminer le nombre de VTV, de MVC et de MB au total que vous traitez avec une demande d'archivage. Oracle vous recommande vivement, en conséquence, d'exécuter dans un premier temps ARCHIve sans MOVEVTV, puis d'ajuster la tâche comme requis avant de spécifier MOVEVTV. Pour plus d'informations, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Etant donné que l'archivage à la demande peut solliciter considérablement les ressources, vous devez généralement exécuter ARCHIve aux heures creuses. Vous pouvez également utiliser l'utilitaire ARCHIve pour remplacer les réglages CONFIG RECLAIM THRESHLD, MAXMVC et CONMVC afin d'optimiser les performances d'archivage. Vous pouvez aussi indiquer le temps d'archivage maximum, en minutes, dans le paramètre ELAPSE. Notez que plusieurs facteurs restrictifs ont un impact sur les archives (par exemple, MAXMVC et ELAPSE). Le VTCS applique le facteur restrictif le plus strict. Par exemple, si vous exécutez ARCHIve, réglez ELAPSE sur 5 heures et MAXMVC sur 10, et que le VTCS archive 10 MVC en une heure, le VTCS interrompt alors l'archivage avant l'expiration de la valeur ELAPSE.
Le VTCS et le HSC doivent être actifs pour pouvoir traiter une requête ARCHIve, sauf si vous définissez le paramètre POLICYdd. POLICYdd (qui force le mode "rapport uniquement") fournit également une fonction améliorée de "scénario de simulation". Vous pouvez créer une ou plusieurs instructions MGMTclas alternatives avec différentes stratégies d'archivage (différentes valeurs ARCHAge et ARCHPol) et utiliser POLICYdd pour afficher la stratégie d'archivage et l'utilisation des ressources dans chaque scénario.
L'utilitaire RECONcil est similaire à l'utilitaire ARCHive, car RECONcil déplace également les VTV d'une classe de stockage vers une autre (c'est-à-dire d'un média MVC vers un autre et/ou d'un ACS vers un autre). Pour percevoir la différence entre ces deux outils, envisagez ARCHive comme un utilitaire proactif et RECONcil comme un utilitaire réactif, comme décrit à la section "Rapprochement des médias et de l'emplacement des VTV".
Si le délai de 365 jours s'est écoulé et aucun auditeur interne n'a demandé à consulter les données, il est alors temps de les archiver. L'exemple ci-dessous illustre un JCL permettant d'exécuter ARCHive comme suit :
Archivez les VTV contenus dans les classes de gestion COMPLY sur un média 9940 dans l'ACS distant.
Réglez MAXMVC sur 60, CONMVC sur 8 et ELAPSE sur 60 pour la tâche ARCHive.
//ARCHIVE EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * ARCH MGMT(COMPLY) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
Astuce :
Le paramètre MOVEVTV vous fournit également un rapport afin de déterminer si vous vous en êtes bien sorti (ou non). Si vos paramètres de réglage n'ont pas permis d'archiver toutes les données que vous souhaitiez archiver, apportez les ajustements nécessaires à votre tâche, puis réexécutez l'utilitaire.L'utilisation de RECONcil pour rapprocher le média et l'emplacement des VTV consiste fondamentalement à déplacer les VTV d'une classe de stockage vers une autre. Cela revient-il archiver les données avec ARCHive ? En termes de mouvements des données, oui. En termes de motifs vous incitant à effectuer cette opération, ce déplacement est plus réactif que proactif. En règle générale, vous procédez au rapprochement des VTV dans les circonstances suivantes :
Les VTV ne se trouvent pas sur le bon média, dans le bon ACS ou les deux.
Un ACS est indisponible pendant une longue période, puis il est remis en ligne. Dans ce cas, vous devez d'abord modifier le paramètre MIGpol dans l'instruction MGMTclas afin que les VTV concernés pointent vers un autre ACS (et média, le cas échéant). Lorsque l'ACS d'origine est remis en ligne, vous devez alors modifier le paramètre MIGpol dans l'instruction MGMTclas de manière à désigner l'ACS d'origine, puis exécuter RECONcil en spécifiant les instructions MGMTclas (ou STORclas) actualisées afin de déplacer les VTV vers l'ACS d'origine.
Pour plus d'information sur le processus de rapprochement, reportez-vous à la section "Exemple RECONcil".
Si vous voulez procéder au rapprochement des VTV qui ne se trouvent pas sur le bon média ni dans le bon ACS, comment faire pour le déterminer ? Examinez vos rapports VTV une fois par semaine, comme décrit à la section Gestion du HSC et du VTCS. Cette semaine, vous observez que tous les VTV de votre classe de gestion de production (PROD) ne résident pas sur le bon média, ni dans le bon ACS. La classe de stockage ne semble pas non plus correcte.
Qu'est-ce qui a bien pu se passer ? Vous pensez que vous avez fait ce qui suit :
STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P MGMT NAME(CUSTA) MIGPOL(CUSTA) MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2) MGMT NAME(PROD) MIGPOL(LOC)
D'après cet exemple, tout le contenu de la classe de gestion PROD aurait dû finir sur le média 9840 dans l'ACS local ; or, tout est sur le média 9940 dans l'ACS distant, comme si tout était dans la mauvaise classe de stockage.
Après un examen plus approfondi, il semble que la classe de gestion de production se présente comme suit :
MGMT NAME(PROD) MIGPOL(CUSTA)
Cela est incorrect pour une autre raison, car cela signifie que les données de production coexistent sur les mêmes MVC que celles qui sont supposées être dédiées à l'un de vos clients. Il est donc temps d'exécuter l'utilitaire RECONcil, n'est-ce pas ? Peut-être que non. L'utilitaire RECONcil se contente de déplacer les VTV hors de la classe de stockage erronée. Or, à ce stade, d'après la manière dont vous avez rédigé l'instruction de votre classe de gestion, CUSTA est la bonne classe de stockage ! Par conséquent, avant d'exécuter RECONcil, vous devez revenir en arrière et corriger la classe de gestion comme suit :
MGMT NAME(PROD) MIGPOL(LOC)
Vous pouvez à présent exécuter RECONcil comme décrit ci-dessous :
Déplacez les VTV contenus dans la classe de gestion PROD vers leur emplacement correct (mis à jour) dans la classe de stockage LOC.
Réglez MAXMVC sur 60, CONMVC sur 8 et ELAPSE sur 60 pour la tâche RECONcil.
//RECONCIL EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * RECON MGMT(PROD) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
Pour sélectionner les VTV à rapprocher, vous pouvez spécifier l'un des paramètres suivants :
MGMTclas pour déplacer les VTV vers les classes de stockage spécifiées par le paramètre MIGpol. C'est ce que nous avons fait à la section "Exemple RECONcil". Etant donné que la classe de gestion pointe vers une classe de stockage incorrecte, corrigez-la de sorte qu'elle désigne la classe de stockage appropriée, puis exécutez RECONcil sur la classe de gestion mise à jour.
STORclas pour déplacer les VTV vers les classes de stockage spécifiées. Vous utiliserez probablement cet utilitaire quand un ACS est indisponible pendant une longue période.
MVC pour rapprocher les VTV figurant dans une liste ou une plage de MVC. Les VTV sont déplacés vers les classes de stockage spécifiées par le paramètre MIGpol des instructions MGMTclas pour les VTV. Vous pouvez utiliser cet utilitaire d'abord, puis l'option VTV.
VTV pour rapprocher une liste ou une plage de VTV. Les VTV sont déplacés vers les classes de stockage spécifiées par le paramètre MIGpol des classes de gestion pour les VTV.
Remarque :
Si vous ne spécifiez pas de valeur pour MGMTclas ou VTV, le VTCS analyse tous les VTV.
Etant donné que le rapprochement des VTV peut solliciter de nombreuses ressources, vous devez généralement exécuter RECONcil aux heures creuses. Vous pouvez aussi utiliser l'utilitaire RECONcil pour remplacer les réglages CONFIG RECLAIM THRESHLD, MAXMVC et CONMVC afin d'optimiser les performances du rapprochement. Vous pouvez également indiquer le temps de rapprochement maximum, en minutes, dans le paramètre ELAPSE.
Notez que plusieurs facteurs restrictifs ont un impact sur les rapprochements (par exemple, MAXMVC et ELAPSE). Le VTCS applique le facteur restrictif le plus strict. Par exemple, si vous exécutez RECONcil et réglez ELAPSE sur 5 heures et MAXMVC sur 10, et que le VTCS effectue le rapprochement de 10 MVC en une heure, le VTCS interrompt alors les rapprochements avant l'expiration du délai ELAPSE.
Si vous ne définissez pas le paramètre MOVEVTV, vous pouvez obtenir un rapport (uniquement) qui offre un "scénario de simulation" utile pour déterminer le nombre de VTV, de MVC et de MB au total que vous traitez avec une demande de rapprochement. Oracle vous recommande vivement, en conséquence, d'exécuter dans un premier temps RECONcil sans MOVEVTV, puis d'ajuster la tâche comme requis avant de spécifier MOVEVTV.
Pour plus d'informations, reportez-vous au manuel Référence des commandes, des instructions de contrôle et des utilitaires ELS.
Le VTCS et le HSC doivent être actifs pour traiter une requête RECONcil, sauf lorsque vous spécifiez le paramètre POLICYdd. POLICYdd (qui force le mode "rapport uniquement") fournit également une fonction améliorée de "scénario de simulation". Vous pouvez créer une ou plusieurs instructions MGMTclas alternatives avec différentes stratégies de rapprochement (différentes valeurs MIGpol) et utiliser POLICYdd pour afficher les VTV rapprochés et l'utilisation des ressources dans chaque scénario.
Le VTCS et le HSC doivent être actifs pour traiter une requête RECONcil.
Les pools MVC nommés sont l'outil adéquat pour tous vos groupes d'intervention : vous pouvez les utiliser pour attribuer la propriété des MVC à une application dans le pool nommé. Par exemple, un groupe d'intervention peut choisir d'utiliser des pools MVC nommés si ses clients sont tenus par la loi d'acheter et de posséder un groupe de MVC.
Toutefois, si vous n'avez pas une exigence spécifique concernant les pools MVC nommés mais vous voulez regrouper ou séparer les données de clients sur les MVC, Oracle vous recommande vivement de ne pas utiliser les pools MVC nommés. Optez plutôt pour les méthodes décrites dans les sections suivantes :
Regroupement de plusieurs charges de travail sur des MVC partagées
"Ségrégation de charges de travail individuelles dans des jeux de MVC séparés".
Les sections ci-dessus vous expliquent comment utiliser des classes de stockage pour regrouper ou séparer les données sur les MVC sélectionnées à partir du pool MVC système. Dans ce cas, vous ne devez gérer qu'un seul pool MVC.
Si vous créez des pools MVC nommés, vous devez explicitement gérer chaque pool, ce qui implique de veiller à ce que chaque pool ait suffisamment de MVC libres et de l'espace MVC disponible, et éventuellement de définir différentes stratégies pour chaque pool à l'aide des paramètres MVCPool MVCFREE, MAXMVC, THRESH et START.
Si vous choisissez d'utiliser des pools MVC nommés, allez à la section "Création et utilisation de pools MVC nommés".
Pour créer et utiliser des pools MVC nommés, procédez comme suit :
Modifiez les instructions POOLPARM existantes et/ou ajoutez des instructions supplémentaires pour définir les pools MVC nommés.
Si vous ne spécifiez pas le paramètre POOLPARM NAME, le VTCS ne crée pas un sous-pool MVC nommé et affecte les volumes indiqués au pool par défaut (DEFAULTPOOL). Vous ne pouvez pas créer de pools MVC nommés portant les noms réservés DEFAULTPOOL et ALL.
Vous pouvez utiliser les paramètres MVCFREE, MAXMVC, THRESH et START facultatifs pour spécifier les valeurs du pool MVC nommé qui remplacent les valeurs globales indiquées dans CONFIG.
Par exemple, les instructions VOLPARM et POOLPARM suivantes définissent une plage de volumes pleins T10000 à chiffrer pour le pool nommé SYS1MVCT1 avec des valeurs de paramètres de récupération qui remplacent les valeurs globales :
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE) POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
Exécutez SET VOLPARM pour appliquer les définitions de volume et de pool :
SET VOLPARM APPLY(YES)
Définissez des classes de stockage et associez-les aux pools MVC nommés.
Par exemple, l'instruction STORclas suivante définit STORCL1 et associe cette classe de stockage au pool nommé MVC CUST1POOL. Les demandes d'utilisation de MVC pour la classe de stockage STORC1 entraîne la sélection des MVC dans le pool nommé SYS1MVCT1 uniquement.
STOR NAME(STORCL1) MEDIA(T!AE) MVCPOOL(SYS1MVCT1)
Créez des classes de gestion qui spécifient les classes de stockage que vous avez définies à l'étape 3 et indiquez ces classes de gestion lorsque vous acheminez des données vers le pool MVC nommé.
Pour plus d'informations, reportez-vous à la section "Création et utilisation des classes de gestion et de stockage VTCS : Principes fondamentaux".
Indiquez le nom de la classe de gestion à VTCS dans ce qui suit :
Instruction SMC TAPEREQ.
Routines SMS que vous écrivez dans l'interface StorageTek DFSMS. Pour plus d'informations, reportez-vous à Configuration et administration du SMC.