La restauration de Base de données SQL Server - la Clé principale est de ne Pas ouvrir
Je dois faire une copie locale d'un Serveur SQL server distant de la base de données. Je l'ai fait en utilisant les Tâches > Sauvegarde de Gestion de Studio. J'ai ensuite localement restauré la sauvegarde, ce qui semble tout avoir-des tableaux, des utilisateurs, clé symétrique, et un certificat.
Lorsque je tente d'effectuer une sélection qui m'oblige à ouvrir la clé symétrique et déchiffrer par le certificat, j'obtiens cette erreur:
Please create a master key in the database or open the master key in the session before performing this operation.
Pourquoi suis-je demandé, et pourquoi ne pas s'ouvrir automatiquement, comme c'est le cas sur le serveur distant?
J'ai essayé de changer la clé principale, mais sans le mot de passe d'origine, je ne peux pas faire grand chose.
peut-être que je suis absent quelque chose d'évident ici; sur la machine d'origine, vous n'avez pas besoin d'ouvrir la clé, il vous suffit d'exécuter la procédure stockée. Est-il une faille dans mon export/import?
La façon la plus simple de résoudre ce problème est de sauvegarder la base de données de la clé principale et de lui attribuer un mot de passe pour protéger le fichier. Puis restaurez la base de données maître de la clé à l'aide du mot de passe de la base de données restaurée. Cela fonctionne sans que vous ayez besoin de connaître le mot de passe d'origine utilisé pour créer la DMK aussi longtemps que la DMK est également crypté par le SMK sur votre système de production, ce qui est fait par défaut, sauf si le chiffrement par clé est supprimée.
OriginalL'auteur ashes999 | 2011-06-16
Vous devez vous connecter pour publier un commentaire.
Le problème est le SMK a changé (depuis la machine a changé). Il y a un article expliquant qu'il ici. Il suffit d'exporter et d'importer les SMK -- en gardant à l'esprit que toutes les données chiffrées dans votre copié-système sera illisible.
Articles MSDN:
OriginalL'auteur ashes999
Voici un bon article en particulier sur la migration d'une base de données qui inclut le chiffrement:
http://www.sql-server-performance.com/2009/migrating-databases-checklist-part3/3/
Mais en bref, vous devez connaître le mot de passe d'origine afin de le déplacer.
Vous pouvez sauvegarder et restaurer la clé (c'est à dire reproduire comme vous le mentionnez), mais vous aurez besoin d'accéder au serveur à distance, la capacité de créer des copies de sauvegarde ou d'une copie de sauvegarde avec des mots de passe d'origine:
http://msdn.microsoft.com/en-us/library/ff848768.aspx
Cette conversation du forum peut également s'avérer utile pour comprendre:
http://www.sqlservercentral.com/Forums/Topic775644-146-1.aspx
OriginalL'auteur RThomas
Même problème résolu sans perte de données - si vous avez le mot de passe de la création de la clé principale
De la clé primaire dans la base de données a été chiffré par la Clé principale du Service. Il ouvre automatiquement lorsque vous avez utilisé la clé maître.
Maintenant la Clé principale du Service est impossible d'ouvrir la clé principale, et SQL est vous invitant à "OUVRIR le MAÎTRE de la CLÉ de DÉCHIFFREMENT PAR MOT de passe = 'mot de passe'" manuellement ou la création de la clé maître.
Ajout d'un chiffrement par le NOUVEAU Service du SERVEUR de Clé principale sera de nouveau autoriser l'ouverture automatique de la clé maître.
Bravo au gars qui a répondu à la question dans le lien
OriginalL'auteur Alocyte
Vous ne pouvez pas contourner le chiffrement. Voir ce lien pour le mot officiel de Microsoft.
OriginalL'auteur RC_Cleland
Tout d'abord, je n'ai pas la réputation cred de commentaires sur d'autres posts. Si je le faisais, je voudrais des commentaires sur le a accepté de répondre pour dire que j'en ai vu d'autres ici se plaindre quand quelqu'un répond à tout un tas de liens, mais pas de son contenu, car au fil du temps, les liens vont mal. Je me joins à cette plainte. N'ont pas le cred pour mon bas-vote du compte, mais je le bas-voté de toute façon.
Alors, je suis en train de travailler à travers la mise en place d'un plan de maintenance sauvegarde, qui comprend une base de données avec quelques colonnes chiffrées. Tout fonctionnait très bien, sauf que ce même problème: sur le serveur de restauration, j'ai dû ouvrir la DMK (base de données master key) avant l'ouverture de la clé symétrique (ou de faire inline déchiffrement), quelque chose de pas nécessaires sur le serveur d'origine.
J'ai utilisé les mots clés de la recherche dans Google à partir de l'URL de la mort lien ci-dessus dans l'acceptation de réponse, ce qui m'a conduit à ceci:
restaurer la base de données ayant le chiffrement à d'autres serveur
Court de il est, après la restauration de la DMK sur le serveur cible, je lance la suite de sorte que le SMK (service master key) permettra de maintenir le mot de passe pour la DMK et de l'ouvrir automatiquement si nécessaire:
Désormais la cible imite le comportement (de façon transparente décryptage) de la source.
OriginalL'auteur John Chase