假設您想將所有任務關鍵型數據庫整合到一個實例中，以便您可以節省一些許可費用，那麼潛在風險是什麼？有沒有關於此的好文章或案例研究？我意識到這是一個可怕的想法，但我有一個人想要做到這一點，並願意最大限度地提高硬件資源，如果需要的話。我想向他介紹一些可以量化的東西或者一些可以使他遠離這種做法的文章。爲什麼你不想整合任務關鍵型數據庫？
有三大關鍵任務數據庫，其中包括賬單，Dynamics CRM和一個內置的應用程序來跟蹤事務。這些是針對中小型公司的高容量數據庫。我需要量化或好的案例研究支持，以便說服某人這是走錯的道路。關於如何說服這個人的任何其他建議也會有幫助。
答案取決於。乍一看，這可能看起來不太好。另一方面，如果目標是將所有內容整合到一臺服務器上，然後在遠程環境中複製該服務器，那麼您即將獲得更可靠的系統。 IT可能更喜歡把所有東西都放在一個地方，而不是處理散佈在地形上的關鍵任務服務器。
一個主要問題是需要更大的機器。因此，如果任何系統使用的軟件的許可證沒有取決於機器的大小，那麼您最終會花費更多錢，因爲您需要更大的服務器。例如，我已經看到這種情況發生在SAS授權中。
但是，最大的問題也許是不同的應用程序可能處於不同的開發週期 - 無論是內部開發還是外部開發商開發。所以，更新硬件/操作系統/軟件可能會變成一場噩夢。 A中的一個修復或增強功能可能需要一個操作系統修補程序，而該修補程序又未在B上進行過測試。此維護問題是我強烈建議單獨服務器的原因。
也就是說，任務關鍵型應用程序就是這個關鍵任務。硬件上的驅動因素不應該是幾美元。驅動因素應該是可靠性，維護，性能，可持續性和恢復。
有兩個極端。 1.永遠不要把所有的雞蛋放在一個籃子裏。 （避免單點故障。）2.確保籃子非常非常好後，將所有雞蛋放入一個籃子。 （大多數通過移動到單個服務器來節省資金的IT程序會遺漏掉最後一點。） – 2012-07-12 19:24:33
Oded，Catcall和Gilbert發表了評論。
我學習IT交易的銀行在單個MVS（後來的Z/OS）主機上運行其整個核心業務，該主機運行單個DBMS和單個事務處理器（除非將TSO計爲事務處理器）。
交易處理器定期關閉（比如每天一次）。它從來沒有導致銀行破產，因爲它在不到一分鐘的時間內總是恢復運行。里程可能會有所不同，但在整個工作日（480分鐘或< 0.25％）內丟失一分鐘的營業時間確實不會造成危險的破壞性。
單個數據庫管理系統也出現故障，有時（比如每個月兩次）。我仍然可以聽到系統管理員大喊大叫「DBMS已經關閉」到服務檯人員，這意味着「期望獲得用戶呼叫」。它從來沒有導致銀行破產，因爲它在幾分鐘內一直運行起來。里程可能有所不同，但每個月丟失幾分鐘的營業時間實際上不應該具有危險的破壞性。
有一次，我記得銀行真的接近破產的時候，開發團隊已經把銀行絕對核心業務中的一個新項目弄得一團糟，銀行也完全失業（其真正的業務）連續三天或四天。那不是0。業務時間損失25％，但幾乎超過100倍。
我的故事的道德？他們兩個人。 （a）關於風險評估（=概率評估）和風險加權（=概率加權）成本評估。 （b）如果你提出一個關於SO的問題（這意味着一種認可/期望回答者在主題上比你擁有更多的專業知識），像Oded和Catcall這樣的人給你一個簡明的答案，這是準確的，並且這一點，那麼不要求文件或案例研究來支持他們的答案。如果你不想接受專家的專業知識，那麼爲什麼還要問什麼呢？
謝謝。我確實接受他們的專業知識，事實上我完全同意他們，但我需要說服別人，爲了做到這一點，我需要好的案例研究來說服他們。 – m0g 2012-07-13 12:51:27
統一實例關閉，所有關鍵任務數據庫都關閉... – Oded 2012-07-12 16:31:11
單點故障。 – 2012-07-12 16:37:41
我希望一些支持文章或案例研究來支持這一點。 – m0g 2012-07-12 17:36:02