使用Oracle 10g。這個項目的原始Oracle設計師已經開始工作，我們這些人仍然是Oracle的合理開發人員，但我們需要一些調整和計劃方面的幫助。Oracle 10g中包的大小對性能的影響
我們在'喜歡'的軟件包中有劃分的程序，其中一些（許多）程序的規模已經擴大到包含許多（50個）不同複雜程度的程序。
此時，這些較大包中的幾個小程序（從Contract中選擇ID ='xyz'）需要比預期更長的時間（從TOAD，SQL Developer或來自。 NET Oracle提供程序），而不是如果proc是自行編譯或更小的程序包。 （表索引）
即使調用相對簡單的單個過程或者是否存在一些我們應該尋找的「其他」因素，是否應該使用這樣的大包的性能成本？
（注：升級到Oracle 11計劃但不是「迫在眉睫」）
第一次在一個包中的任何方法被調用時，整個包需要被讀入內存。一般來說，如果你在一個包中調用一個方法，那麼這應該是一個優點，很可能許多相關的方法將被你調用的一個過程或後續的應用調用調用。但這確實意味着第一次執行可能會因加載更多代碼而減慢，這對簡單函數來說可能是嚴格必要的。然而，一旦包裝被加載到內存中，該懲罰就會消失。這聽起來不像是你正在談論一個程序的第一次調用的執行問題，但是，這往往會排除這一點。
在小程序執行之前，程序包的初始化塊是否有任何代碼可能會導致結果偏差？
你是如何確定調用這些小程序需要多長時間以及「更長」意味着什麼的？你是否稱他們爲少數幾個毫秒，並且看到執行時間增加30％？還是你打電話給他們幾千次，看到執行時間增加1000％？
這在加載和初始化之外發生，所以在這種情況下不是問題。目前我們正在'觀察'執行時間多長時間沒有進行基準測試。如果我們在腳本窗口中從Toad執行，或者作爲「小」（僅此項目）包的一部分，則響應在更大的包中是「即時」（sub second ..），它是3到5秒。 （使用完全校準的「1密西西比」方法。 –
@OMG，我們已經建立了基於包裝大小-_should_-不影響過程性能的Oracle軟件包，但我們看到了計數器指標並正在研究這種可能性。 –