如何撤銷 DBADM 並從 DB2 LUW 中清除任何相關對象
這個問題之所以出現是因為我們複製了生產備份並將它們恢復到較低的環境（當然是亂碼數據），以供開發人員練習和/或調試。
我們有分配的 ID
DBADM、SECADM、DATAACCESS和ACCESSCTRL（主要是實例所有者）。當我們恢復到較低的環境時，我們最終需要以原始實例所有者的身份登錄，並將上述相同的權限（DBADM、SECADM、DATAACCESS和ACCESSCTRL）授予新的目標實例所有者。我認為將原始 ID 留在數據庫中不是一個好主意，所以我試圖撤銷它的權限。在我的包重新綁定開始失敗後不久，因為顯然有包綁定到該原始 ID。不知道它們包含什麼以及我是否可以/應該刪除它們（即使我認為刪除它們是無害的？？？）我最終將權限恢復到原始實例所有者並將其留在那裡。
這一直困擾著我。
DBADM具有,SECADM,DATAACCESS和的權力的 IDACCESSCTRL不應該只是到處亂放。對我來說，這是一個安全漏洞。對我來說，應該撤銷 ID，並且應該執行任何其他需要執行的清理以確保數據庫安全。如果說我會退出公司或我的 DBA 同事會退出，情況也是如此。我們希望撤銷 ID 並清理和/或轉移對象的所有權以消除任何安全漏洞。問題是，我不知道需要清理什麼。我在 Google 和 IBM 的文件上進行了一些探索，但我找不到任何建議從系統中刪除如此高的使用者時通常應該採取的步驟。甚至是有
BINDADD權限的使用者？你們都刪除/撤銷什麼以及以什麼順序？有沒有辦法可以腳本化/自動化？你怎麼知道你可以刪除哪些包？還有其他需要移動/轉移的東西嗎？
還有人遇到這種情況嗎？想法？經驗？
您可能需要考慮幾個方面。
首先，您可以在恢復期間使用DB2_RESTORE_GRANT_ADMIN_AUTHORITIES 系統資料庫變數自動為目標實例所有者分配適當的權限。如果在還原之前將其設置為 ON，則執行還原的使用者將獲得這些權限。
其次，大多數綁定/編譯問題來自這樣一個事實，即只有對象所有者，即首先創建對象的授權 ID，才被授予對其執行某些操作的權限。如果您在生產中作為實例所有者執行 DDL 腳本，那麼無論 DB2_RESTORE_GRANT_ADMIN_AUTHORITIES 設置如何，這將是還原後所有對象的所有者 ID。當然，您可以使用TRANSFER OWNERSHIP 語句來改變它，但在現實生活中，數據庫中有成千上萬個對象，這可能不切實際。
為了避免“次要”部分，在許多組織中，人們使用與實例所有者分開的特殊“建構器”授權 ID 來執行 DDL 腳本。此 ID 不會被賦予任何不必要的特權，可以受到嚴格控制，並且當存在於所有環境中時，應該能夠執行所有必要的任務而不會增加安全風險。