2Gb or Not 2Gb - File limits in Oracle (Part I)
2024-08-29 13:30:52
供稿：網(wǎng)友
2gb or not 2gb - file limits in oracle
翻譯：kamus（seraphim）
校正：bloomit
郵件：[email protected]
日期：2004-1
經(jīng)常會聽說導入導出的時候，備份恢復的時候，sql*loader導入數(shù)據(jù)的時候，文件超出了2g大小，結(jié)果導致錯誤。
本人文科畢業(yè)，什么二進制，十六進制，數(shù)據(jù)結(jié)構(gòu)，操作系統(tǒng)等等的一概沒有學過，所以對此問題一直都只有一個模糊的認識，今天在metalink上面閑逛，忽然發(fā)現(xiàn)了這篇文章，興之所致，決定好好看看，看完以后，感覺對于此問題明白了很多，于是就順便翻譯成了中文，希望對大家也有所幫助。
對于本文中提及的所有其它notes和bugs也做了盡可能的整理（還未翻譯，以后如果有時間再慢慢作），只是文中提到的一些bug由于本人metalink帳號的限制亦或是bug的不公開性，并不能看到詳細描述，對于這樣的bug就無法再作整理。
原文出處：http://metalink.oracle.com
doc id: note:62427.1 原文創(chuàng)建日期：1998-9-2 原文最后更新日期：2003-8-6
介紹
本文闡述了“2gb”問題，解釋了為什么2gb會是一個這樣充滿魔力的數(shù)字，并且如果你想在oracle的應(yīng)用中使用超過2gb大小的文件，那么這篇文章也告訴了一些你應(yīng)該知道的事情。
本文以unix操作系統(tǒng)為基礎(chǔ)，因為大部分的2gb問題都發(fā)生在unix上面，當然文中也提到了一些對于其它非unix操作系統(tǒng)的相關(guān)資料，在本文的最后一節(jié)列出了各個操作系統(tǒng)自己的限制。
本文主題包括以下幾點：
l 為什么2gb是一個特殊的數(shù)字？
l 怎樣使用超過2gb（2gb+）的文件？
l 導出（export）和2gb
l sql*loader和2gb
l oracle和其它2gb問題
l 不同操作系統(tǒng)上的“大文件”(large files)
為什么2gb是一個特殊的數(shù)字？
很多當前正在使用的cpu和api都使用了32位（bit）的字長，而正是這個字長對于很多操作產(chǎn)生了影響。
眾多的場合下文件操作的標準api在對文件大小和文件中當前位置的處理都使用了有符號32位字（32-bit signed word）。一個有符號32位字以最高位來表示正負，所以只剩下31位來存儲真正的數(shù)值，而16進制中存儲在31位中的最大正值就是0x7fffffff，也就是10進制中的+2147483647，這正是一個臨近2gb的值。
2gb或者更大的文件一般被稱為“大文件”，當你在32位環(huán)境中使用2147483647甚至更大的數(shù)字時，你就很可能會碰到一些問題。為了解決這些問題，最新的操作系統(tǒng)已經(jīng)重新定義了一系列完全利用64位尋址方式來操作文件大小和偏移量的系統(tǒng)函數(shù)。最新的oracle發(fā)行版也已經(jīng)使用了這些新的接口，但是如果在你決定要使用“大文件”以前，你仍然有不少的問題需要考慮。
另外一個特殊的數(shù)字是4gb。也就是作為無符號字（unaigned value）的十六進制數(shù)字0xffffffff（十進制是4294967295），這是一個略小于4gb的值。將該值加一將使低4位字節(jié)成為0x00000000，同時產(chǎn)生'1'進位。這個進位在32位運算中將會失去。所以4gb也是一個可能會產(chǎn)生問題的特殊數(shù)字。本文中對這個問題也有所提及。
對于使用oracle這意味著什么？
32bit的問題在不少方面都影響到了oracle，為了使用“大文件”，你需要滿足以下條件：
1. 一個支持2gb+文件的操作系統(tǒng)或者裸設(shè)備（raw devices）
2. 一個具有支持存取2gb+文件的api的操作系統(tǒng)
3. 一個使用了這些api的oracle版本
今天大多數(shù)的平臺都已經(jīng)支持了大文件，并且對于這些文件有64bit的api，oracle7.3及以后版本一般已經(jīng)使用了這些api，但是根據(jù)不同的平臺，不同的操作系統(tǒng)以及不同的oracle版本仍然有很多不一樣的情況。在一些場合下默認就是支持“大文件”的，但是另外一些場合卻可能必須要打一些補丁。
一直到寫這篇文章的時候，oracle里面還有一些工具是沒有更新到使用這些新的api的，比如眾所周知的export和sql*loader，不過仍然再次強調(diào)一下，由于平臺和操作系統(tǒng)的不同，情況還是不一樣的。
為什么要使用2gb+的文件？
在這一節(jié)中我們試著總結(jié)一下對于oracle的數(shù)據(jù)文件使用大文件和設(shè)備（"large" files / devices）的優(yōu)點以及缺點。
使用大于2gb文件的優(yōu)點：
l 在大多數(shù)平臺上oracle7支持最多1022個數(shù)據(jù)文件。如果文件小于2g，那么也就是限制了數(shù)據(jù)庫的大小只能是小于2044gb。當然這對于支持了更多數(shù)據(jù)文件的oracle8來說已經(jīng)不再是個問題（oracle8支持每個表空間中包含最多1022個數(shù)據(jù)文件）。
l 在現(xiàn)實情況中oracle7的最大數(shù)據(jù)庫尺寸會比2044gb小，因為一般數(shù)據(jù)文件都存放在單獨的表空間中，而很多數(shù)據(jù)文件就可能遠遠小于2gb。使用大文件可以讓數(shù)據(jù)庫超越2044gb的這個限制。
l 使用大文件意味著對于較小的數(shù)據(jù)庫只需要管理較少的文件。
l 需要較少的文件處理資源。
使用大于2gb文件的缺點：
l 恢復的單位更大了。一個2gb文件的備份和還原，根據(jù)備份媒體和磁盤速度的差異，會耗費15分鐘到1個小時的時間，那么一個8gb的文件就要花4倍這樣的時間。
l 備份和恢復的并行操作新能將會收到影響。
l 會碰到一些平臺特有的限制，比如說在超過2gb以上異步i/o的操作就可能會變成線性操作。
l 處理2gb以上的文件可能會需要補丁或者一些特殊的配置。相對于小文件來說也會有更大的風險性。比如在一些aix的發(fā)行版上，超過2gb，異步i/o就會使用線性操作。
使用大于2gb文件的要點：
l 跟操作系統(tǒng)提供商確認，大文件是否被支持，同時要如何去配置。
l 跟操作系統(tǒng)提供商確認，真正的最大文件限制是多少？
l 詢問oracle技術(shù)支持，確定對于你現(xiàn)有的平臺，操作系統(tǒng)版本，oracle版本，是否需要什么補丁或者還有什么限制？
l 記住，如果你真的考慮對于操作系統(tǒng)或者oracle要打一些補丁的話，那么就再檢查一遍上面提到的這些問題。
l 確認對于所有要使用大文件讀取的用戶來說，操作系統(tǒng)的限制已經(jīng)正確設(shè)定。
l 確認所有的備份腳本都能夠處理大文件。
l 注意，對于使用超過2gb的數(shù)據(jù)文件，對于最大文件大小還有一個限制。這個限制依賴于你的系統(tǒng)平臺以及oracle初始化參數(shù)db_block_size。在大多數(shù)平臺上（包括unix, nt, vms）文件大小的限制在4194302*db_block_size這么大。
[note:112011.1]文檔描述了改變文件大小中存在的問題，特別是超過了2gb的時候。
一般需要注意的要點：
需要小心設(shè)置文件的自動擴展。明智的作法是在不使用“大文件”的場合下，將自動擴展的數(shù)據(jù)文件最大尺寸限制在2gb以下。另外注意由于[bug:568232]將有可能定義一個超過oracle處理極限的maxsize數(shù)值，這在resize之后將會引發(fā)一個內(nèi)部錯誤（錯誤顯示為ora-600 [3292]）
在很多平臺上，oracle數(shù)據(jù)文件的頭部都包含著附加的數(shù)據(jù)塊，所以創(chuàng)建一個2gb的數(shù)據(jù)文件實際上需要比2gb更多的磁盤空間。在unix平臺上數(shù)據(jù)文件頭部的附加數(shù)據(jù)塊大小通常等于db_block_size的大小，但是在裸設(shè)備上可能需要占用更多一些的空間。
2gb相關(guān)的oracle錯誤
當2gb限制到達的時候可能會發(fā)生下面這些錯誤，這些錯誤的產(chǎn)生沒有特定的順序。
ora-01119 error in creating datafile xxxx
ora-27044 unable to write header block of file
svr4 error: 22: invalid argument
ora-19502 write error on file 'filename', blockno x (blocksize=nn)
ora-27070 skgfdisp: async read/write failed
ora-02237 invalid file size
kcf:write/open error dba=xxxxxx block=xxxx online=xxxx file=xxxxxxxx file limit exceed.
unix error 27, efbig
