
ヘディングのテキスト### ヘディングのテキスト### 旧筐体上の一データベースに作成されていたユーザアカウントで 新筐体後もログインしたい。(復元後)
旧筐体側に設定されていたように、目的のログインアカウントに対し ユーザと既定のスキーマの設定(dbo)を追加すると 以下のとおりエラーになる。
ユーザー 'dbo' の作成に失敗しました。 (Microsoft.SqlServer.Smo) ユーザー、グループ、またはロール 'dbo' は現在のデータベースに既に存在します。 (Microsoft SQL Server、エラー: 15023)
試したこと
以下Webサイトに 対策の記事が紹介されていたので、試しに行いました。しかしエラーとなり進展を得ません。
リストア後のDBでUser Mappingができない場合にやったこと(SQL Server)
SQL
1exec sp_change_users_login @Action = 'Update_One' 2 ,@UserNamePattern = 'dbo' 3 ,@LoginName = 'HogeHoge' 4 5メッセージ 15287、レベル 16、状態 1、プロシージャ sp_change_users_login、行 40 [バッチ開始行 0] 6このプロシージャを終了しています。'dbo' はこのプロシージャのログイン名パラメーターでは禁止されている値です。
お分かりになられる方 解決策をご教示頂けますでしょうか?
ログインアカウントに対し設定されていたユーザ「dbo」というものが 特殊な位置づけなのですかね???
2023/05/16 15:50追記
旧:SQL Server 12
新:SQL Server 15
旧環境にてKEMONO_PANTSU_k さんが仰るように スクリプト生成を試行➡➡➡失敗
新環境にてKEMONO_PANTSU_k さんが仰るように スクリプト生成を試行➡➡➡以下のように作成された
2023/05/17 19:25 追記
2023/05/18 12:48 追記 バックアップファイルからの復元の操作
2023/05/18 13:42 追記
2023/05/18 15:36 追記 「復元しています」が ず~っと現れている。 1時間以上経過...

ログイン自体は作成されていますでしょうか?(すでに存在していますでしょうか?)
sp_change_users_loginは既存のユーザーとログインをマッピングするためのもののようでしたので、
'dbo'ユーザーは存在するとして、'HogeHoge'ログインも存在しないとエラーになりそうに思いました。
*見当違いのことを書いてしまいましたらごめんなさい・・
dboは既定のスキーマみたいですね。
> dbo スキーマ
> dbo スキーマは、すべてのデータベースの既定のスキーマです。
> https://learn.microsoft.com/ja-jp/sql/relational-databases/security/authentication-access/ownership-and-user-schema-separation?view=sql-server-ver16#the-dbo-schema
sp_change_users_loginよりALTER USERを使用した方が良いみたいですね。
> sp_change_users_login (Transact-SQL)
> この機能は、Microsoft SQL Server の将来のバージョンで削除されます。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。 代わりに ALTER USER を 使用してください。
> https://learn.microsoft.com/ja-jp/sql/relational-databases/system-stored-procedures/sp-change-users-login-transact-sql
1番最初のスクショに、このログインにマップされたユーザ という文字が見えるとおり、ログインアカウント自体は存在しているのかな、という認識です。

ご返信ありがとうございます。
> 1番最初のスクショに、このログインにマップされたユーザ という文字が見えるとおり、ログインアカウント自体は存在しているのかな、という認識です。
プロパティはすでに表示されているログインを右クリックして表示したものということなのですかね。
ログイン名は'HogeHoge'で正しいのでしょうか?
他の人は具体的なユーザー名やログイン名は把握できていないと思いますので、
伏せるのはOKですが、補足で説明しておいてもらえると助かります。
ちょっと調べてみて(うろ覚えの記憶を思い出してみて)、
旧環境でユーザーが本当に「dbo」だったか確認してもらいたいと思いました。
「ログインアカウント自体は存在しているのかな」というのは、復元した時点でログインも作成(復元)されていたということでOKでしょうか?
(新しい環境で一から作ったものではない)
復元後にSIDが不一致になるのは”あるある”だと思うのですが、
それは次の引用のようにすると解消できると思います。
*このケースだと、ユーザーに「dbo」が指定されていることはなさそうな気もしますね・・
> WITH LOGIN 句を使用すると、ユーザーを別のログインに再マップできます。 ログインのないユーザー、証明書にマップされているユーザー、非対称キーにマップされているユーザーを、この句を使って再マップすることはできません。 SQL ユーザーおよび Windows ユーザー (またはグループ) のみ再マップできます。 WITH LOGIN 句は、Windows アカウントを SQL Server ログインに変更するなど、ユーザーの種類の変更には使用できません。
> SID の不一致は別のサーバーからデータベースを復元し、データベース ユーザーを SQL Server ログインにマップした場合に発生することがあります。 WITH LOGIN 句を使用して、データベース内のユーザー SID をサーバーのログイン SID に置き換えることで、この状況を改善できます。
> https://learn.microsoft.com/ja-jp/sql/t-sql/statements/alter-user-transact-sql?view=sql-server-ver16#remarks
> D. SID の不一致を修正する
> 次の例では、SQL Server 認証のログインでサーバー上の SID と一致するように、データベースのユーザー SID を修正しています。
> ```sql
> ALTER USER Mai
> WITH LOGIN = Mai;
> GO
> ```
> https://learn.microsoft.com/ja-jp/sql/t-sql/statements/alter-user-transact-sql?view=sql-server-ver16#d-correct-a-mismatched-sid
念の為、旧環境、新環境のそれぞれのバージョンなどもご記載いただけますでしょうか。
*古いバージョンでできていたこと(ユーザーに「dbo」を指定する)が新しいバージョンでできなくなったとかあるのかなとも思いました
ご返信をありがとうございます。
ログイン: HogeHoge は新筐体側で 再度定義したものです。(実際は異なります、問い合わせの文面上変更いたしております)
旧筐体でもおなじログイン名を所有しており、
最初に示したスクショは 旧筐体側のログインアカウントのプロパティを新筐体側でも真似ようとして生じたエラーです。
たしかに復元したデータベースのユーザに dboが既に実在しているので、ログインアカウント側からdboのユーザアカウントをマッピングしようとして 重複検知なってしまう状況は 容易に推察できます。
(dboユーザは 削除することさえ許されていないようで)
困ったなぁ
旧筐体の当該データベースの構築担当は 現在おりませんもので
旧:SQL Server 12.
新:SQL Server 15

ご返信ありがとうございます。
バージョンなどの情報は質問欄を修正することでご記載いただけますと助かります。
(他の回答者の方は質問欄をまず見ると思いますので)
旧環境の情報をもう少し提示してもらいたいのですが、
ログインのプロパティから上のタイトルバー付近に「スクリプト」ボタンがあると思います。
このボタンによって、同じ設定を再現するためのスクリプトを生成することができますので、
そのスクリプトも質問欄にご記載いただけますでしょうか。
*本当に「dbo」ユーザーにマッピングされているのか、確認できるのかなと思っています
多分、「dbo」はスキーマとして使っているだけじゃないかなと思っています
*念の為旧環境のマッピングのスクリーンショットも貼り付けてもらえると助かります
お付き合いをありがとうございます、本文に追記を図りました。

ご返信ありがとうございます。
質問欄の編集もありがとうございます。
本当に、旧環境のユーザーが「dbo」になっているみたいですね・・
ごめんなさい。私じゃお力になれなそうでした・・
旧環境のスクリプトが作成できないのですね・・
この旧環境は「SQL Server ログイン」でしょうか?
特殊なログインだったりしますでしょうか?
dbo ユーザーと dbo スキーマ
https://learn.microsoft.com/ja-jp/sql/relational-databases/security/authentication-access/principals-database-engine?view=sql-server-ver16#dbo-user-and-dbo-schema
リンク先を読んでみましたら、
「dbo」はデータベースの所有者のことみたいでしたので、
旧環境ではそのログインがデータベースの所有者だったのでしょうか・・?
新しい環境でも所有者になれば同じにすることができるのでしょうか・・?
*ごめんなさい。私自身この辺りの理解が十分ではありません・・
最初に聞いておくべきだったとは思いますが、、
現在の状況における具体的な問題は何でしょうか?
具体的な問題についても質問欄にご記載いただけますと助かります。
*設定が同じではないと思いますが、それによって表面化している問題です
*例えば
”対象の「ログイン」を使ってアプリからデータベースが参照できない(具体的なエラーメッセージ)”という表面化した問題があるとしたら、
設定は同じにはならないけど、その表面化した問題が解消できればOK、だったりしますでしょうか?
SSMS・SQLServer認証で 問題のログインアカウントで ログインできるも
復元したデータベースのツリーを展開できない、という問題に直面しています。
筐体がWindowsServer2012のためサポート切れに由来し、筐体刷新を行う必要が出てきました。
ベンダー様が導入したWebシステムのDBであり、移行作業を今回委託しているので 正直 新筐体だけ手配したので あと宜しく! と言ってしまえば いいのかも知れません。
当該システム用に作成された DBのユーザぐらいまでは 対応・DBアクセスができるようにしておこうと思ってのことでした。
ちなみに、本文に追記したスクリプト生成やSSMSでの操作は 新環境も旧環境でも『sa』を利用した試行でした。
諦めるかなぁ… できる限りのことを進めておこうとおもったんだけれど。

ご返信ありがとうございます。
そういう状況だったのですね。
結局、最終的な移行日に全部対応することになると思いますので、
余計なことはせずに業者に渡した方が間違いがないと思いました。
*余計なことをすると逆に間違いが起こる気がしました・・
*データベースも移行日時点のデータを復元しなおすことになると思いますし
復元したデータベースをとりあえず確認したいということでしたら、
dboにマッピングしようとせず、
新しいログイン用のユーザーを作成する形で進めた方が良いと思いました。
確認が終わって、業者に渡す段階になったら、
「新しいログイン」と「新しいユーザー」は削除した形で渡してあげると親切だと思いました。
仰るとおり、決定する移行日に旧筐体から再度バックアップを復元するので、あまりこだわってもホント仕方ないんですけれどね。
単なる自己満足に付き合わせて非常に申し訳なかったです、すみません。
もうベンダーに任せます。IISもセットアップしておいてあげたし…
ありがとうございました。

ご返信ありがとうございます。
ちょっと思いついたことがありましたので、
もし試す余裕がありましたら
試してみてください。
*手元にSQL Serverの環境がなく、先のコメントから思いつくままに書いてしまってすみません・・
今回の新環境のデータベースは(インスタンスではなくデータベース)、
復元によって作ったものということですよね?
復元はSSMSにログインしている「sa」で操作したのですよね?
そうだとすると、
”「dbo」はデータベースの所有者のこと”みたいですので、
一度、「sa」で「新しいログイン」を作って、
その「新しいログイン」にデータベース作成権限なども付与して、
「新しいログイン」でSSMSにログインし直して、
(復元ではなく)新しい空っぽのデータベースを作成してみたら、
状況はいかがでしょうか?
この時点で、
その「新しいデータベース」の「dbo」と「新しいログイン」が
マッピングされた状態になるのではないかと思いました。
*「新しいデータベース」を作ったのは(所有者は)、「新しいログイン」ですので
この状態にした上で、
すでに作成済みの「新しいデータベース」に対して
復元をかけることで想定通りの状況にすることができるのではないかと思いました。
色々とご親切な見解 誠にありがとうございます。
現在社屋を離れているので 明日試せるようなら行って報告させて頂きますね。
既に既定のデータベース名を新筐体に存在させてしまっているので、こちらを別名に変更して、あらたに同名のデータベースを再定義できるだろうか という点が若干不安です。
(新筐体上のデータベースといえ、削除の操作は気が引けるんです、度胸なくすみません)

遅くまでお疲れ様です。
> (新筐体上のデータベースといえ、削除の操作は気が引けるんです、度胸なくすみません)
ご心配でしたら無理して試すことはないとは思いますよ。
*データベースの名前を変更するというのはちょっと影響がわからないので、逆に私は怖いです・・
(Oracleとか使った経験からでしょうか・・)
こういったことは、「SQL Server Developer edition」か、
「SQL Server Express edition」で試せる環境があると良いかもしれませんね。
仰られたとおりに DBを新設する試行を行いました。この過程で 既定の所有者を選択することができたので 話題にしてきたログインアカウントに選択してみたところ 旧環境と同様に dboを ユーザと既定のスキーマに設定することができました。(状況は本文一番最後から2番目のスクショ)
安心するのもつかの間、こちらは当然からっぽのデータベースなので こちらに対し、旧筐体からのバックアップを復元してあてがおうとしたところ、失敗に終わりました。 一筋なわではいきませんね
(この状況は本文の一番下のスクショです)

ご返信ありがとうございます。
試してみたのですね。
> 旧環境と同様に dboを ユーザと既定のスキーマに設定することができました。(状況は本文一番最後から2番目のスクショ)
なるほど。
saで接続しつつ、データベースの所有者を変更することができるのですね。
> こちらに対し、旧筐体からのバックアップを復元してあてがおうとしたところ、失敗に終わりました。 一筋なわではいきませんね (この状況は本文の一番下のスクショです)
確か、この画像の下の方に復元対象のデータベースを選択できるところがありましたよね?
その項目はどのように指定しました?
*新たにデータベースを作成しつつ復元する場合と指定方法が異なっていたような記憶があります
エラーメッセージもどこかに出力された気がするので、
そちらもご提示いただけると助かります。
ご返信をありがとうございます。
まだ諦めてない感じで頼もしいですね。
明朝、再実施してスクショを撮り直します。データベースからの復元でなく メディアからの復元を選択して ファイルダイアログから 旧筐体側から複写した .bakのファイル指定した感じですね
また詳細は 後日ご連絡致します。
バックアップからの復元手順のスクショを 更に追加しました。
当方が示した手続きではなく ファイルおよびファイルグループ を選択して 行うべきなのでしょうか?
復元についても 不慣れですみません。
話題が変わってきてしまいましたね....

ご返信ありがとうございます。
> 当方が示した手続きではなく ファイルおよびファイルグループ を選択して 行うべきなのでしょうか?
多分、ご記載いただいた内容で良さそうですね。
転送先のデータベースは、「新しいデータベース」(空っぽの)を指定しているのですよね?
やっぱりエラーメッセージが見たいですね。
「データベースの復元に失敗しました」のバーをクリックするとエラー内容が表示されたりしなかったでしたっけ?
(ちょっと以前の状況から引き続き操作しているとすると、ファイルの名前が重複していたりしないかな?と気になったりはします)
(データベースの名前を変更したとしてもファイルの名前は前のままだったような気がしますので)
> 話題が変わってきてしまいましたね....
確かに、当初の内容であるログインのユーザーのマッピングはとりあえず解消できたのですよね。
画像を追加しました。
尚、データベースを新規で作りだす際に、従来同名が復元されていたので そちらのデータベース名および、mdfファイルとlogファイルの名称を予め変更しています。更にデタッチもしてある状態で当該データべース新設しました。
やはり 以前復元した同名データベースがなにか悪さしているのでしょうk

コメントやスクリーンショットをありがとうございます。
エラーメッセージやオプションのスクリーンショットを見ますと、
オプションタブの復元オプションの
「既存のデータベースを上書きする」のチェックが必要でした。
*もしかしたら、これをするとログインとユーザーのマッピングもクリアされてしまうかもしれませんね・・
復元オプション
[既存のデータベースを上書きする [WITH REPLACE]]
https://learn.microsoft.com/ja-jp/sql/relational-databases/backup-restore/restore-database-options-page?view=sql-server-ver16#restore-options
公式ではないのですが、
次のリンクなども見てみてください。
https://www.ipentec.com/document/sql-server-restore-database-in-different-name-in-same-database-server
---
> データベースの所有権
> 復元されたデータベースのシステム管理者または新しいデータベース所有者は、そのデータベースの所有権を変更できます。
> https://learn.microsoft.com/ja-jp/sql/relational-databases/databases/manage-metadata-when-making-a-database-available-on-another-server?view=sql-server-ver16#database_ownership
もしかしたら、普通に復元したデータベースの
所有権を「希望するログイン」のものに変更するだけで、
dboとログインのマッピングを想定通りにできたのかもしれませんね・・
*知識不足で色々意見が変わってしまい、すみません・・
---
> 尚、データベースを新規で作りだす際に、従来同名が復元されていたので そちらのデータベース名および、mdfファイルとlogファイルの名称を予め変更しています。更にデタッチもしてある状態で当該データべース新設しました。
ちゃんと考慮されていて、素晴らしいですね。
お付き合いを頂き 誠にありがとうございます。
先程本文へ追加致しましたが 現況を報告すると 前回の操作の影響とみえ「復元しています」という表示が続いている状況です。
厄介なことに 当該データベースへのアクセスが saでも拒否される状況で1時間以上が経過しました。
ま、明朝迄放置してみますが...
ちょっと先行き怪しいですね
「復元しています」、を右記コマンドを実施して終了させ(RESTORE DATABASE [DatabaseName] WITH RECOVERY;)
「既存のデータベースを上書きする」にチェックをつけて 復元を再試行してなんとか復元は完了しました。ご推察どおり「*もしかしたら、これをするとログインとユーザーのマッピングもクリアされてしまうかもしれませんね・・」 でした。
振り出しにもどった認識なので 早速仰られる「復元したデータベースの
所有権を「希望するログイン」のものに変更するだけで、」を試行したいのですが 具体的にどうすればよいのか 分かりません。 ご紹介のMSの記事拝見したのですが、所有者を変えることができるの記載ありも どういった操作から変えられるのか 言及されていないように思いました。
引きつづき もし お手間でなければ ご見解頂けますと助かります!

コメントありがとうございます。
> 復元を再試行してなんとか復元は完了しました。
よく復元できましたね。
> ご推察どおり「*もしかしたら、これをするとログインとユーザーのマッピングもクリアされてしまうかもしれませんね・・」 でした。
手間をかけさせてしまっただけのようで、すみません・・
> 振り出しにもどった認識なので 早速仰られる「復元したデータベースの 所有権を「希望するログイン」のものに変更するだけで、」を試行したいのですが 具体的にどうすればよいのか 分かりません。
ちょっと調べてみましたので、
下に記載しますね。
---
データベースのプロパティを表示しても
「所有者」の欄は無効の状態になっているのですね。
---
ALTER DATABASEと思ったのですが、
ALTER AUTHORIZATIONで変更できるみたいですね。
*使ったことがないです・・
> 既定では、開発者がスキーマにオブジェクトを作成した場合、そのオブジェクトは、開発者ではなく、そのスキーマを所有するセキュリティ プリンシパルによって所有されることになります。 オブジェクトの所有権は、Transact-SQL ステートメント ALTER AUTHORIZATION で転送できます。
> https://learn.microsoft.com/ja-jp/sql/relational-databases/security/authentication-access/ownership-and-user-schema-separation?view=sql-server-ver16
---
> F. データベースの所有者を変更する
>
> ```sql
> ALTER AUTHORIZATION ON DATABASE::Parts TO MichikoOsada;
> ```
>
> https://learn.microsoft.com/ja-jp/sql/t-sql/statements/alter-authorization-transact-sql?view=sql-server-ver16#f-changing-the-owner-of-a-database
*「Parts」の部分がデータベース名で、「MichikoOsada」の部分がログイン名でしょうか
---
ちょっと、別のことをまた思いついたのですが、
復元も、データベースを上書きによって作り直した(所有し直した)と考えられるのだとしたら、
復元する際の操作を「新しいログイン」で操作すれば良かったのでしょうかね?
*でも、Webアプリのログイン用のものに強い権限を付与してしまうことはあまり望ましいことではなさそうですよね・・
手取り早く saではなく 新筐体に追加したログインアカウントでSSMSにログインして、
データベースの復元を再試行しようとしました。→→→復元先のフィールドや復元プランのペインが空のままになってしまい、どうやら 無理っぽいですね。
今からALTER実施してみます。
KEMONO_PANTSU_k様
お陰様で 当初から思い描いていたゴール、ログインアカウントに対して ユーザと既定のスキーマへdboを設定することができました。
当該のログインアカウントでSSMSへログインして、復元したデータベースのツリーを展開することができるようになりました。
長期にわたり また諦めずにご支援を頂き 誠にありがとうございました。

コメントありがとうございます。
> お陰様で 当初から思い描いていたゴール、ログインアカウントに対して ユーザと既定のスキーマへdboを設定することができました。
解決したようで良かったです!
---
> →→→復元先のフィールドや復元プランのペインが空のままになってしまい、どうやら 無理っぽいですね。 今からALTER実施してみます。
こちらは権限的な問題だったのかな?と思いました。
> RESTORE (Transact-SQL)
> 権限
> 復元するデータベースが存在しない場合、ユーザーは RESTORE を実行できる CREATE DATABASE 権限を使用する必要があります。データベースが存在する場合、既定では、RESTORE 権限は sysadmin 固定サーバー ロールおよび dbcreator 固定サーバー ロールのメンバと、データベースの所有者 (dbo) に与えられています。
> https://learn.microsoft.com/ja-jp/previous-versions/sql/sql-server-2005/ms186858(v=sql.90)?redirectedfrom=MSDN#権限
おそらく所有者はもう違うものに変わってしまっていたと思いますので、、
sysadmin、dbcreatorのいずれかの権限が「新しいログイン」に必要なのかもしれないですね。
今後、必要になったりしたら、思い出してみてくださいね。
解決済みにする意味合いで記載したら、自己解決なってしまい KEMONO_PANTSU_kさんの功績として表示されなくなってしまい 非常に申し訳ない気持ちです!
本当今回助かりました、自分一人では 解決策を導き出せませんでした。

コメントありがとうございます。
自己解決で良かったと思いますよ。
申し訳ないなんて思うこともないです。
最初から`ALTER AUTHORIZATION`できていればすぐに解決できていたと思いますので、、
私のコメントで逆に遠回りしてしまいましたね・・

回答1件
あなたの回答
tips
プレビュー