為什麼作業會使用 dtexec.exe 呼叫批處理文件，而不是直接呼叫 SSIS 包？
我繼承了一個 SQL 2012 伺服器，其中包含許多呼叫 SSIS 包的作業。
這些作業不是更明顯的解決方案（直接從“SSIS 包”作業步驟呼叫它們），而是使用 CmdExec 步驟呼叫批處理文件，其中包含一行：
dtexec.exe /FILE "D:\path\PackageName.dtsx"為什麼以前的 DBA 會這樣做？權限？個人喜好？
為什麼要雙跳？如果您想使用 dtexec.exe，您不能直接將該命令放在作業步驟中嗎？
我知道如果包中使用了 MS Office 組件，有時包中的 32 位和 64 位依賴項可能會出現問題。我怎麼知道這是否是這裡發生的事情？
在 SQL Server 2012和項目部署模型之前，從 SSMS 上下文執行 SSIS 包的唯一方法是 SQL 代理作業或 xp_cmdshell。
SQL 代理正在呼叫DTEXEC.exe，因為它有一個特殊參數
/X86，該參數僅在從 SQL 代理傳遞時才會受到尊重。否則，您需要指定 dtexec.exe 的顯式路徑以控制它是 32 位還是 64 位操作。此選項僅由 SQL Server 代理使用。如果在命令提示符處執行 dtexec 實用程序，則忽略此選項。
選項 A
這可能是他們使用批處理文件啟動 SSIS 包的原因。他們希望確保使用正確的 dtexec 來執行包。關於確定是 32 還是 64 的無恥自我宣傳http://billfellows.blogspot.com/2015/02/is-my-ssis-package-running-in-32-or-64.html還有https://stackoverflow。 com/a/13092260/181965
選項 B
我看到使用批處理腳本的另一個原因是它們不使用配置（文件、表等），但希望在每個環境中獲得不同的行為。假設我的 SSIS 包中有一個 ConnectionString 變數並且設計時值是 Dev 但現在我在生產中，更改該值的一種方法是在我們執行時始終設置屬性，psuedocode 是
dtexec.exe /file MyPackage /SET ConnectionString;Prod如果我很懶惰，我可以在所有環境中使用相同的作業定義，但
/SET可以根據需要更改值的內容。我認為它沒有那麼有用，但有些人以不同程度的難度看待任務。以上內容不一定只適用於/SET。他們可以設置日誌記錄或其他任何東西。也許他們想將輸出記錄到執行日誌中，因為他們不知道 SSIS 本身就支持該功能。開發批處理文件中可能有
/REP EWIP > CurrentRun.txt，但生產只有/REP E選項 C
另一個原因是安全的幻覺。在前雇主，他們使用批處理腳本方法來執行 SSIS 包。開發人員未被授予訪問 SQL 代理的權限。xp_cmdshell - 哦，地獄不。我們也不能被信任登錄到預生產框（Load、stage、UAT），但我們仍然需要按需執行 SSIS 包。
因此，在每次包需要執行時送出緊急請求票數週後，他們創建了一對提供封閉包執行體驗的儲存過程。RunSSISPackage 和 RunSSISPackage32 將採用要執行的包的名稱。對於我們創建的每個包，他們都會創建一個執行它的批處理腳本。各方都有很多忙碌的工作，但當時這是他們讓我們執行包裹的唯一方式。這些程序使用 xp_cmdshell 和 EXECUTE AS 允許我們以完全的系統管理員權限執行這些包。順便說一句，當您允許人們在沒有審核的情況下部署 SSIS 包時，他們可以在其中添加一個執行 SQL 任務，將開發人員組添加到 sysadmin 角色中。我想。可能是。假設。
選項 D
不是 SQL 代理。我見過在非 SQL 代理的客戶端上使用的其他調度工具。特別是對 SSIS 的支持參差不齊，但它們都支持批處理文件，所以也許你有一些與 SSIS 不兼容的企業調度程序。
否則，如果它只是 dtexec.exe /file foo.dtsx …我什麼都沒有
首先（如果您還不知道）DTExec 是用於執行 SSIS 包的命令行工具。據我所知，甚至 SQL 作業都在幕後使用 DTExec。
至於他們為什麼使用 bat 文件而不是本機 GUI 步驟，我無法告訴你。可能是他們更喜歡 bat 文件，或者甚至不知道 SQL 作業中有該選項。或者就此而言，他們可以使用不同的調度工具開發作業，然後將對 bat 文件的呼叫移動到 SQL 作業中，而不必修改任何內容。
我自己在 32 位和 64 位方面遇到了很多問題。我唯一可以告訴你的是，你可以在 32 位模式下執行該包，以便使用 32 位驅動程序。