DB2 開發人員不能在自己的模式中創建表，但 SQL 和 Oracle 開發人員可以。有道理嗎？
作為一名剛接觸 DB2 的開發人員，當我發現無法在開發數據庫環境中創建自己的表時，我感到很驚訝。所以，我向 db2 DBA 提出了一個問題。我不想因為質疑政策而造成太多麻煩，並希望更好地了解我們阻止開發人員創建表的政策是否適合 DB2。
問題： 我知道您必須遵守政策，但您知道為什麼我們公司可能會創建一個僅限 DB2 的政策，以防止 DB2 開發人員在他們自己的模式中創建表，同時允許 SQL Server 和 Oracle 開發人員這樣做嗎？
答： 大型機是比 Oracle 和 SQL 更受控制的環境。我們公司內的所有應用程序都共享 DB2 子系統。在 Oracle 或 SQL 中，每個應用程序都有自己的實例，它們的測試不會影響另一個實例。
– DB2 大型機不像 Oracle 那樣在同一個文件中創建多個表。因此，在大型機上，如果您能夠在測試中創建表，那麼如果您創建了一個巨大的表，您可能會用完所有的 dasd，如果您要針對那個巨大的表進行測試，它可能會耗盡子系統的排序空間，edm游泳池等 大小適合測試環境。–DB2 Mainframe 應用程序共享子系統和所有系統資源。每個測試 db2 子系統都根據該 DB2 子系統的功能確定大小…… DB2T – 測試，DB2F – 系統測試，DB2B – 生產支持。它們都有不同的尺寸公差。
對 SO 的問題： Re：“如果您創建了一個巨大的表，您可能會用完所有 dasd”DB2 是否沒有能力通過模式來限制空間使用以防止開發人員用完所有 DASD（我認為是磁碟訪問儲存設備/又名磁碟空間）？查找首字母縮略詞 EDM 並找到“環境描述符管理器”，我認為這是包含所有表定義的內容，例如主數據庫。這是一個特定於 DB2 的有效問題嗎？
從 DBA 的回答中，我大致了解我們的架構是這樣的，即每個環境（例如 TEST、UAT 等）都不會在單獨的實例中執行，並且一個實例會影響另一個實例，但聽起來好像是這種情況，那麼我們已經遇到了這個問題，因為開發人員能夠將數百萬行插入為他們創建的表中。真正的威脅不是我創建的表的大小而不是創建表的能力嗎？我認為 DB2 DBA 應該能夠將開發人員限制在安全水平。
他們這樣做可能是因為大型機上的儲存分配比 unix 或 windows 平台複雜得多。
zOS 基本上是一個非常現代的複雜硬體和作業系統，它模擬 1960 年代的大型機。與最新的英特爾晶片模擬 1980 年代 386 晶片的方式大致相同。
問題在於，在原始硬體上獲得高頻寬和快速訪問時間所必需的接近線磁碟 I/O 的非常低的級別被“嵌入”到作業系統和許多應用程序中。因此，遺留應用程序的所有磁碟儲存都處理通道和卷。卷是具有 8GB 或 32GB 儲存空間的“假裝”3330 磁碟，通常分配為真正的 nTerabyte RAID 系統的一部分。
要在 zOS DB2 中正確定義表，您需要創建表空間，而這又需要您在特定卷上分配儲存，這相當麻煩，因為需要將四個或五個實體連結在一起 TABLE -> TABLESPACE -> Volume Group -> Disk Volumes + 索引 -> 索引表空間 -> 卷組 -> 磁碟捲。
基本上，您的 DBA 通過不讓您參加比賽來為您省去很多麻煩。
PS 如果您使用現代的 zOS（Unix 系統服務）的一半，這一切都變得無關緊要，但這將是一個漫長而緩慢的遷移！
不允許開發人員擁有可以進行更改的沙箱的文化正在發生變化。現在有許多商店允許開發人員創建和更改模式開發人員沙箱模式，特別是用於原型設計。有一些允許某些類型的更改（例如更改添加列）。
儲存管理員可以定義策略來控製沙盒環境可用的磁碟數量。