none
OS移行後、SQL Server 2005 のストアドから、外部の共有フォルダが参照できない。 RRS feed

  • 質問

  • OS移行後、SQL Server 2005 のストアドから、外部の共有フォルダが参照できない。

    SQL Server 2005のOSを移行しています。

    移行前(旧サーバ):
     OS・・・Windows Server 2003 R2 Standard Edition SP2 32bit
     サーバ名・・・SERVER1
     所属・・・ワークグループ workgroup1
     SQL Server・・・Microsoft SQL Server 2005
     SQLサーバ接続情報
      ・サーバーの種類:データベースエンジン
      ・サーバ名:SERVER1\hoge
      ・認証:SQL Server 認証
      ・ログイン:aaa
      ・パスワード:bbb
      
    移行後(新サーバ):
     OS・・・Windows Server 2008 R2 standard 64bit
     サーバ名・・・SERVER2
     所属・・・ドメイン example.local
     SQL Server・・・Microsoft SQL Server 2005
     SQLサーバ接続情報
      ・サーバーの種類:データベースエンジン
      ・サーバ名:SERVER2\hoge
      ・認証:SQL Server 認証
      ・ログイン:aaa
      ・パスワード:bbb

    共有フォルダのあるサーバ(共有サーバ):
     OS・・・Windows Server 2003 R2 Standard Edition SP2 32bit
     サーバ名・・・SERVER3
     所属・・・ワークグループ workgroup2
     IP・・・111.111.111.111
     共有フォルダ名・・・hoge

    移行前に正常動作していたストアドが、移行後の環境でエラーとなってしまいます。
    何かアドバイスがいただけたらと思い投稿しました。

    <エラーメッセージ>
    日付,ソース,重大度,ステップ ID,サーバー,ジョブ名,ステップ名,通知,メッセージ,実行時間,SQL 重大度,SQL メッセージ ID,メールを受け取るオペレータ,Net Send 通知を受け取るオペレータ,ポケットベル通知を受け取るオペレータ,再試行の回数
    09/25/2013 14:47:29,HOGE_IMPORT_JOB,エラー,0,SERVER2\HOGE,HOGE_IMPORT_JOB,(ジョブの結果),,ジョブは失敗しました。  ジョブは ユーザー aaa によって起動されました。最終実行ステップはステップ 2 (ファイル削除) でした。  ジョブはステップ 1 (IMPORT_HOGE) で開始するように要求されました。.,00:00:00,0,0,,,,0
    09/25/2013 14:47:29,HOGE_IMPORT_JOB,エラー,2,SERVER2\HOGE,HOGE_IMPORT_JOB,ファイル削除,,次のユーザーとして実行: SERVER2\SYSTEM。ログオン失敗: ユーザー名を認識できないか、またはパスワードが間違っています。.  プロセス終了コード 1。.  ステップは失敗しました。,00:00:00,0,0,,,,0
    09/25/2013 14:47:29,HOGE_IMPORT_JOB,不明,1,SERVER2\HOGE,HOGE_IMPORT_JOB,IMPORT_HOGE,,次のユーザーとして実行: NT AUTHORITY\SYSTEM。@FILE_PATH_CSVで指定したファイルが存在していません。 [SQLSTATE 01000] (メッセージ 0).  ステップは成功しました。,00:00:00,0,0,,,,0


    成功(移行前)

    日付,ソース,重大度,ステップ ID,サーバー,ジョブ名,ステップ名,通知,メッセージ,実行時間,SQL 重大度,SQL メッセージ ID,メールを受け取るオペレータ,Net Send 通知を受け取るオペレータ,ポケットベル通知を受け取るオペレータ,再試行の回数
    09/24/2013 18:10:00,HOGE_IMPORT_JOB,不明,0,SERVER1\HOGE,HOGE_IMPORT_JOB,(ジョブの結果),,ジョブは成功しました。  ジョブは スケジュール 3 (HOGEマスタ取り込み) によって起動されました。最終実行ステップはステップ 2 (ファイル削除) でした。.,00:00:03,0,0,,,,0
    09/24/2013 18:10:02,HOGE_IMPORT_JOB,不明,2,SERVER1\HOGE,HOGE_IMPORT_JOB,ファイル削除,,次のユーザーとして実行: SERVER1\SYSTEM。ステップは何も出力を作成しませんでした。  プロセス終了コード 0。.  ステップは成功しました。,00:00:00,0,0,,,,0
    09/24/2013 18:10:00,HOGE_IMPORT_JOB,不明,1,SERVER1\HOGE,HOGE_IMPORT_JOB,IMPORT_HOGE,,次のユーザーとして実行: NT AUTHORITY\SYSTEM。2件データが挿入されました。 [SQLSTATE 01000] (メッセージ 0)  ●●を更新しました [SQLSTATE 01000] (メッセージ 0)  IMPORT_PIYO_PATERN END<c/> iReturnCode = 0 [SQLSTATE 01000] (メッセージ 0).  ステップは成功しました。,00:00:02,0,0,,,,0

    SERVER2からエクスプローラーで \\111.111.111.111\hoge にアクセスすると認証ダイアログが出ます。
    ユーザID:SERVER3\hoge で認証をパスし、共有フォルダを読み書きできます。
    上記エラーはその後の手動ジョブ実行でのエラーです。

    <ストアドについて>
    Transact-SQLを使用しています。
    ジョブからストアドを実行しています。

    ステップ1では、IPsecVPN越しの別ネットワークのサーバの共有フォルダを参照して、
    そこにあるCSVファイルの内容を読み取り、挿入・更新しています。

    ストアドの変数に共有フォルダのパスを格納していますが、
    実行時にパスが認識されないというエラーになってしまいます。

    ステップ2では同共有フォルダのファイルを削除しています。

    実行しているストアド(抜粋)


    USE [DB1]
    GO
    SET ANSI_NULLS ON
    GO
    SET QUOTED_IDENTIFIER ON
    GO
    ALTER PROCEDURE [dbo].[IMPORT_PIYO]
    @DEGUG_FLG BIT
    	,@FILE_PATH_CSV VARCHAR(200)
    	,@FILE_PATH_FMT VARCHAR(200)
    	,@FILE_PATH_ERR VARCHAR(200)
    AS
    SET NOCOUNT ON;
    DECLARE @iReturnCode smallint;
    BEGIN
    BEGIN TRY
    	DECLARE @iTemp SMALLINT;
    	EXEC @iTemp = [dbo].[IMPORT_パターンIF] @DEGUG_FLG
    		,@FILE_PATH_CSV,@FILE_PATH_FMT,@FILE_PATH_ERR;
    	IF @iTemp <> 0
    	BEGIN
    		RETURN 0;
    	END
    
    (省略)

    <ジョブについて>
    ジョブのスクリプトの一部を掲載します。
    2つステップがあり、両方でエラーが出ています。

    (省略)
    
    DECLARE @jobId BINARY(16)
    EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'HOGE_IMPORT_JOB', 
    @enabled=1, 
    @notify_level_eventlog=0, 
    @notify_level_email=0, 
    @notify_level_netsend=0, 
    @notify_level_page=0, 
    @delete_level=0, 
    @description=N'ストアドプロシージャ[IMPORT_PIYO_PATERN]を呼び出しPIYOから\\111.111.111.111\hogeに出力された情報CSV(HOGE_EXPORT_PATTERN)を取り込む。', 
    @category_name=N'[Uncategorized (Local)]', 
    @owner_login_name=N'aaa', @job_id = @jobId OUTPUT
    IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
    
    EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'IMPORT_HOGE', 
    @step_id=1, 
    @cmdexec_success_code=0, 
    @on_success_action=4, 
    @on_success_step_id=2, 
    @on_fail_action=2, 
    @on_fail_step_id=0, 
    @retry_attempts=0, 
    @retry_interval=0, 
    @os_run_priority=0, @subsystem=N'TSQL', 
    @command=N'DECLARE @DEGUG_FLG BIT;
    DECLARE @FILE_PATH_CSV VARCHAR(200);
    DECLARE @FILE_PATH_FMT VARCHAR(200);
    DECLARE @FILE_PATH_ERR VARCHAR(200);
    SET @DEGUG_FLG = 0;
    SET @FILE_PATH_CSV = ''\\111.111.111.111\hoge\HOGE1.CSV''
    SET @FILE_PATH_FMT = ''\\111.111.111.111\hoge\HOGE2.FMT'';
    SET @FILE_PATH_ERR = ''\\111.111.111.111\hoge\HOGE3.ERR'';
    EXECUTE  [dbo].[IMPORT_PIYO_PATERN]@DEGUG_FLG, @FILE_PATH_CSV, @FILE_PATH_FMT, @FILE_PATH_ERR;
    ', 
    @database_name=N'DB1', 
    @flags=4
    IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
    
    EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'ファイル削除', 
    @step_id=2, 
    @cmdexec_success_code=0, 
    @on_success_action=1, 
    @on_success_step_id=0, 
    @on_fail_action=2, 
    @on_fail_step_id=0, 
    @retry_attempts=0, 
    @retry_interval=0, 
    @os_run_priority=0, @subsystem=N'CmdExec', 
    @command=N'del \\111.111.111.111\hoge\HOGE_EXPORT_PATTERN.CSV', 
    @flags=0
    
    (省略)


    <今までの作業経緯>
    1.新サーバセットアップ
    2.旧サーバのDBデータをバックアップ
    3.新サーバに復元
    4.「xp_cmdshell」を有効
    5.旧サーバのジョブをスクリプトで出力
     ステップ1のスクリプト生成で警告あり。
     「警告: 存在しないステップが @on_success_step_id で参照されています。」
     とりあえずスクリプトは生成されているので次に進む
    6.新サーバにジョブを新規登録
    7.OS上から \\111.111.111.111\hoge で共有フォルダにアクセス→認証聞かれる→認証情報入力→共有フォルダ閲覧可能
     参照するCSVファイルも置く
    8.新サーバでジョブを手動実行→エラー
    9.「SQLサーバー構成マネージャー」→「SQLサーバ ネットワーク構成」で、「hogeのプロトコル」にて旧サーバと
     異なっている箇所があったので合わせる。
      共有メモリ:有効
      名前付きパイプ:無効→有効(修正)
      TCP/IP:有効
      VIA:無効
      変更後「SQL Server (JOMO)」を再起動して試すが、ジョブ手動実行はエラー。
    10.旧サーバで手動でジョブを実行→正常動作
    11.ジョブのプロパティで新旧で異なる点が合ったので合わせるが、ジョブ手動実行はエラー。
    12.新旧でWINDOWSのサービスを比較して差異が合ったので合わせるが、ジョブ手動実行はエラー。
    Secondary Logon:停止→開始
    バックグラウンド インテリジェント転送サービス:停止→開始
    13.共有サーバの共有フォルダを別のものに変えてみるが、ジョブ手動実行はエラー。
    14.新サーバでIPv6が有効になっていたので無効にしてみたところ、ジョブ手動実行が正常になる。
    15.新サーバのネットワークがずっと「識別中」だったため、OSを再起動したあと試したら、ジョブ手動実行はエラー。
     新サーバのネットワークは正常。
    @FILE_PATH_CSV の値を \\127.0.0.1\hoge にしてみたところ正常動作する。(hogeフォルダはテストで作成)

    以上です。



    • 編集済み EDRN 2013年10月2日 8:10
    2013年10月2日 8:08

回答

  • 見当外れであれば申し訳ありませんが、
    SQL Server の「サービスを起動しているユーザ」が認証出来ていない様な気が・・・
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月2日 11:35
  • Systemだとネットワークリソースへの資格情報はコンピューターアカウントが使われます。しかも、ドメインに参加していないとダメだと思います。よって、共有フォルダにその設定が無ければアクセスできないのは当然だと思うのですが、なぜ以前はアクセスできていたのかがわかりません。

    こちらが参考になるかもしれません。

    ローカルシステムアカウントでサーバーの共有フォルダのファイルを参照したい。
    http://social.msdn.microsoft.com/Forums/ja-JP/5a04ab56-3a30-4bdb-8070-4afd3a190870

    可能であればですが、共有フォルダのあるサーバーをドメインに参加させてみると良いかもしれません。(かつ、SERVER2のコンピュータアカウントをアクセス可にする設定が必要?)
    もしくはSQL Serverのサービスを特定のサービスで動かすことでしょうか。Network ServiceにしてもSystemと同じ資格情報が使われますし、Local Serviceではネットワークリソースにアクセスできません。

    私もこの分野に関してはそれほど詳しくないのですが、やはりなぜ以前はアクセスできていたのかが気になります。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    • 回答の候補に設定 星 睦美 2013年10月22日 1:45
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月17日 8:25
  • EDRN さま よろしく。

    前の環境が workgroup による共有公開だったから、
    ドメインを挟む事で認証が変わってしまったからではないでしょうか。
    以下のサイトが参考になる様な気がします。
      もし、見当違いならお許し下さい。


    ワークグループのWindowsServer2008R2の共有フォルダを無条件でアクセスできるようにする
    http://www.mizusima-soft.co.jp/archives/887

    • 回答の候補に設定 星 睦美 2013年10月22日 1:44
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月18日 14:17

すべての返信

  • 見当外れであれば申し訳ありませんが、
    SQL Server の「サービスを起動しているユーザ」が認証出来ていない様な気が・・・
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月2日 11:35
  • 回答ありがとうございます。

    SQL Server 構成マネージャー→SQL Server (HOGE)のプロパティ→「ログオン」タブ は 「ビルトインアカウント」で「Local System」 になっています。
    旧サーバも同様の設定で共有ファイルを参照できていたので、そのままにしてました。

    選べるのは

    ローカルシステム

    ローカルサービス

    ・ネットワークサービス

    ・このアカウント

    認証ができるユーザとはどれになるのでしょうか?

    それとも共有サーバの方の設定を変える必用があるのでしょうか?


    • 編集済み EDRN 2013年10月7日 6:24
    2013年10月7日 6:23
  • 追加情報です。

    SQLサーバのバージョンです(Select @@version)

    SERVER1\hoge
    Microsoft SQL Server 2005 - 9.00.4053.00 (Intel X86)   May 26 2009 14:24:20   Copyright (c) 1988-2005 Microsoft Corporation  Workgroup Edition on Windows NT 5.2 (Build 3790: Service Pack 2) 

    SERVER2\hoge
    Microsoft SQL Server 2005 - 9.00.5000.00 (Intel X86)   Dec 10 2010 10:56:29   Copyright (c) 1988-2005 Microsoft Corporation  Workgroup Edition on Windows NT 6.1 (Build 7601: Service Pack 1) 

    見てみたら「Workgroup Edition」だったのですが、新サーバではWindowsドメインに参加しています。

    問題ないのでしょうか・・・。(OS・ソフトのセットアップは別の担当が実施しています)

    SP2もあたってないようですね。


    • 編集済み EDRN 2013年10月17日 5:06
    2013年10月17日 4:42
  • Systemだとネットワークリソースへの資格情報はコンピューターアカウントが使われます。しかも、ドメインに参加していないとダメだと思います。よって、共有フォルダにその設定が無ければアクセスできないのは当然だと思うのですが、なぜ以前はアクセスできていたのかがわかりません。

    こちらが参考になるかもしれません。

    ローカルシステムアカウントでサーバーの共有フォルダのファイルを参照したい。
    http://social.msdn.microsoft.com/Forums/ja-JP/5a04ab56-3a30-4bdb-8070-4afd3a190870

    可能であればですが、共有フォルダのあるサーバーをドメインに参加させてみると良いかもしれません。(かつ、SERVER2のコンピュータアカウントをアクセス可にする設定が必要?)
    もしくはSQL Serverのサービスを特定のサービスで動かすことでしょうか。Network ServiceにしてもSystemと同じ資格情報が使われますし、Local Serviceではネットワークリソースにアクセスできません。

    私もこの分野に関してはそれほど詳しくないのですが、やはりなぜ以前はアクセスできていたのかが気になります。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    • 回答の候補に設定 星 睦美 2013年10月22日 1:45
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月17日 8:25
  • EDRN さま よろしく。

    前の環境が workgroup による共有公開だったから、
    ドメインを挟む事で認証が変わってしまったからではないでしょうか。
    以下のサイトが参考になる様な気がします。
      もし、見当違いならお許し下さい。


    ワークグループのWindowsServer2008R2の共有フォルダを無条件でアクセスできるようにする
    http://www.mizusima-soft.co.jp/archives/887

    • 回答の候補に設定 星 睦美 2013年10月22日 1:44
    • 回答としてマーク 星 睦美 2013年10月30日 2:02
    2013年10月18日 14:17
  • EDRN さん、こんにちは
    フォーラム オペレーターの星 睦美です。

    同様の事象で情報をお探しの方にも参考になるように、私からスレッドに[回答としてマーク]させていただきました。
    今後ともSQL Server フォーラムをお役立てください。


    フォーラム オペレーター 星 睦美 - MSDN Community Support

    2013年10月30日 2:05