發現Sybase有個非常有趣的特性，就是支持多個tempdb。雖然一向對Sybase沒什麼好感，但對這個特性還是十分欣賞。查看了一點資料，覺得Sybase自身的一個白皮書比較權威，試着做個翻譯。
概述
當數據庫應用程序需要存儲中間結果或者數據時，就需要臨時空間。在Sybase的旗艦產品 ASE中，這個臨時空間將由一個特殊的系統數據庫tempdb來提供。而且，SQL語句對數據進行處理時，也會用到一些臨時表。所有這些都將導致 tem b50 pdb數據庫的沉重負擔。過去，大量應用對tempdb數據庫中數據和日誌的爭用導致性能下降。
對多個臨時數據庫tempdb的支持在Sybase ASE 12.5.0.3中被引入，在12.5.1中得到完善。該特性使用戶可以創建多個臨時數據庫，並且能夠給應用程序指定一個或多個臨時數據庫作爲該應用程序 的專用庫。有了這個革命性的特性，系統管理員們現在就能對tempdb這項資源有了更強的控制。該特性能夠更好地實現資源分配，增加可用性，提升系統性 能。
特性簡介
多tempdb支持特性使得用戶可以創建多個臨時庫，這些庫又可以在後續的應用中創建臨時對 象。藉助一個系統存儲過程，DBA可以把任何用戶及應用程序綁定到指定的臨時庫或者臨時庫組中。默認組是由系統創建的，系統tempdb就屬於該組。 DBA可以將其它臨時庫加入該組。
登錄/連接建立時，根據存在的綁定，會話就被指定到一個特定的臨時庫中。如果一個登錄賬號被 綁定到一個特定的臨時庫，並且該臨時庫可用，那麼建立的會話就指向該庫；如果登錄賬號沒有綁定，或者綁定的是一個臨時庫組，那麼系統會根據Round- Robin算法（輪詢算法）從默認組中選定一個臨時庫，使會話指向它。
指定給會話的臨時庫在會話終止之前一直有效，並且不會發生改變。該會話所創建的所有臨時對象 也存在於該臨時庫中。該會話中調用存儲過程所創建或訪問的臨時表也存在於該臨時庫中。當會話結束或者服務器停止服務時，所有這些對象都會自動清除。當然， 臨時表也也可以在會話過程中顯式清除。
b50 戶創建的臨時庫跟系統tempdb非常相似，它們都是被用來創建臨時對象，而且，它們中的數據或對象在被清除後是不可被恢復的。跟系統tempdb相比，用戶創建的臨時庫是可以被DBA刪除的。
臨時庫是一種系統資源
在Sybase ASE 12.5.0.3推出之前，對於將臨時庫中的空間分配給各個應用程序這樣的問題，DBA毫無辦法。系統tempdb是被所有應用程序共用的。在此情形下， 要確定能滿足各個應用程序需求的臨時庫大小很難辦到。一個對資源存在大量需求的應用程序可能就會佔光tempdb的全部空間，從而導致一些關鍵應用失敗， 應爲沒有可用的tempdb空間了。在ASE 12.5.0.3中，用戶可以使用以下的語句創建新的臨時庫：
Create temporary database tempdb_1 on tempdb dev = 50
該語句將創建一個名爲tempdb_1的臨時庫。該庫可以被加入默認臨時庫組。ASE 12.5.0.3的用戶手冊“新特性”一節中對於該項新特性有更多的細節。一般來說，在創建用戶數據庫時將日誌和數據存放在不同的設備上總是有益的。但在 創建用戶臨時數據庫時，這樣做卻沒有必要，因爲在寫日誌時“寫”命令被進行了特殊處理，細節將在之後的部分詳述。
要將用戶創建的臨時庫加入默認的臨時庫組，需要使用系統存儲過程sp_tempdb：
Sp_tempdb ‘add’, ‘tempdb_1’, ‘default’
Tempdb_1現在就成爲了默認組的一個成員。所有屬於默認組的臨時庫可以通過如下的語句查看：
Sp_tempdb ‘show’
當用戶建立連接時，ASE數據庫引擎就會根據Round-Robin算法從默認組中選出一個 臨時庫，並指派給該連接。舉例來說，如果默認組中只有兩個臨時庫，所有的應用程序都被綁定到了默認組上，假定有10個用戶連接，那麼5個將被指定到 tempdb，餘下的將被指指定到tempdb_1。這樣就實現了默認組中用戶的負載均衡。
提請注意，應用程序不是必須應用該特性。應用程序創建的所有帶“#”前綴的臨時表都是創建在應用程序連接時就指定的臨時庫中的。
臨時庫也可以隨時脫離所加入的默認組。你可以在負載高峯期配置多個臨時庫來滿足需求，並在高峯期後刪除它們。所有這些操作都不必讓ASE停止服務，也不需要將數據庫設爲單用戶模式。
爲不同應用分配資源
ASE 12.5.1對該特性進行了完善，任何應用或登錄連接都可以被綁定到指定的臨時庫中。舉例來說，假定有兩個應用程序在運行，一個是處理高效OLTP事務 的，另一個是個後臺批處理。OLTP應用就可以綁定到一個創建在RAM盤上的臨時庫上，而那個後臺批處理應用就可以綁定到一個創建在常規磁盤上的較大臨時 庫上，因爲它需要較大的臨時空間。你可以這樣做。
假定OLTP應用程序的名字是“oltp_app”，我們可以用：
Create temporary database oltp_tempdb on ramdev = 50
go
sp_tempdb ‘bind’, ‘AP’, ‘oltp_app’, ‘DB’, ‘oltp_tempdb’
go
假定批處理應用程序的名字是“batch_app”，我們可以用：
Create temporary database batch_tempdb on dbdev = 500
go
sp_tempdb ‘bind’, ‘AP’, ‘batch_app’, ‘DB’, ‘batch_tempdb’
go
這樣，需要大量臨時空間的批處理應用就不會與需要相對較小臨時空間但需要快速響應的OLTP應用產生衝突。
綁定可以被隨時解除是該特性的一個重要體現。而且，用戶創建的臨時庫在較少使用時可以刪除。舉例來說，以上的批處理應用運行結束以後，該臨時庫就可以刪除，從而釋放磁盤空間。如下命令實現這一目的：
Sp_tempdb ‘unbind’, ‘AP’, ‘batch_app’
go
drop database batch_tempdb
go
因爲臨時庫可以被隨時創建和刪除，DBA就可以輕易實現對臨時庫資源的高效管理。
綁定登錄賬號到特定臨時庫是該特性的另一個重要方面。這對於sa賬號尤其重要，該特性能夠幫助DBA在不跟其它應用程序爭臨時庫資源的前提下高效地執行一些關鍵的管理任務。需要用到的命令如下：
Create temporary database sa_tempdb on sadbdev = 100
go
sp_tempdb ‘bind’, ‘LG’, ‘sa’, ‘DB’, ‘sa_tempdb’
go
在ASE 12.5.0.3發佈以前，如果tempdb空間用完，sa也不能執行一些需要用到tempdb空間的存儲過程。有了ASE 12.5.0.3，DBA就可以爲sa保留一個專用的臨時庫。這就保證了sa可以可靠地進入系統，執行管理任務。
類似地，任何用戶登錄都可以被分別綁定到指定的臨時庫上，這樣管理起來就有更大的靈活性。值得注意的是，綁定任意的用戶登錄（不僅僅是sa）是ASE 12.5.1及之後的版本才提供。
服務器結合
現今，IT界的一大趨勢是把一個企業範圍內的各種應用程序放到一起，在一個服務器上運行。當這些應用程序在同一個ASE服務器上運行時，它們很快就會發生衝突，因爲它們共用同一個tempdb。有了多臨 ec8 時庫支持，DBA就能將每個應用程序綁定到合適的臨時庫。
增強的可用性
可用性是企業應用的一項關鍵指標，Sybase在這方面給予了最高程度的重視。有了多臨時庫 支持，在單個臨時庫不可用時DBA們可以不用那麼緊張了。在ASE 12.5.0.3發佈之前，一旦tempdb崩潰，服務器就不得不重啓。但是現在，有了多個臨時庫，DBA們就可以從默認組中刪除崩潰的臨時庫，其它臨時 庫會分擔之後的負載。這項技術顯著降低了系統的宕機時間。
性能提升
多臨時庫支持特性對系統性能的提升表現在兩個主要的方面，更大的事務處理能力（吞吐量）和更短的響應時間。
減少資源爭用
有了多個臨時庫，兩個重要的資源爭用會降低：系統目錄爭用和日誌爭用。
在ASE 12.5.0.3之前，每在tempdb中創建或刪除一個對象，就要往/從tempdb的系統目錄中插入或刪除一行紀錄。這是資源爭用的一個方面。有了多 個臨時庫，這種爭用將顯著降低。一項內部測試表明，在只有一個tempdb時，隨着客戶增加，對系統目錄的爭用急劇增長；增加臨時庫能顯著降低對系統目錄 的爭用。
類似，爲tempdb事務分配多個日誌設備而不是僅分配一個也能極大減少日誌紀錄的瓶頸。其 結果就是，多個臨時庫增大了系統的吞吐量。在我們的測試中，使用兩個臨時庫比一個臨時庫，系統吞吐量增加了至少30%。我們注意到在只有一個tempdb 時，如果系統中的用戶數超過某個數，系統的吞吐量就開始下降。在增加一個臨時庫以後，對系統目錄和日誌的爭用顯著降低，直接導致系統吞吐量的增加。
Tempdb的寫優化
臨時庫是不可恢復的。（在啓動時，ASE會刪除臨時庫並重建。）ASE利用了這一特徵來避免從緩存中寫入數據或日誌到磁盤，而這正是一般數據庫必須做的。
舉例來說，如果一個用戶做了如下的操作：
Select * into tempdb..temp_table from foo
那麼ASE就會在事務結束時清空新建臨時表所緩存的數據。這是因爲select into是一個不紀錄日誌的操作，爲了保證可恢復性，我們就需要保證數據被寫入磁盤。對一般數據庫來說，這是對的；但是由於臨時庫是不可恢復的，ASE 12.5.0.3就會避免在操作結束時把緩存中的數據寫入磁盤。
對一些DML操作比如insert/update/delete ASE並不強制在提交操作時寫日誌。舉例來說，如果用戶進行了以下操作：
Insert into tempdb..temp_table select * from foo
那麼ASE就不會強制在提交操作時寫日誌。這就意味着更少的上下文變換，日誌紀錄和數據設備的負擔更輕，最終增加系統吞吐量。在我們的內部測試中，我們看到過高達50%的寫操作減少。
結論
爲了在關鍵任務環境中給客戶提升價值，Sybase提供了很多特性，ASE 12.5.0.3提供的多臨時庫支持功能強大，保證了更大的吞吐量。ASE 12.5.1所做的完善爲配置管理這一特性提供了更好的靈活性。這份白皮書向DBA們展示了怎樣在不改變應用的情形下，通過配置系統來更好地利用資源。 Sybase相信跟花錢購買這一特性比較起來，特性本身所帶來的企業成本降低是顯著的。