Oracle資料庫挖坑利器-精簡卷
問題現象:
技術交流群裡有位朋友反饋在對Oracle資料庫執行新增資料檔案(
30G大小)操作時,報錯如下,資料庫版本19C:
ORA-19502: write error on file "/xxx/xxx.dbf", block number xxxxx (block size=8192) ORA-27072: File I/O error
問題分析:
建立表空間和新增資料檔案屬於基礎操作,本以為分分鐘搞定的問題,卻一時間難住了眾多大佬。
首先排查磁碟空間剩餘容量,df -h,df -i檢查空間、inode非常充足,遠遠大於30GB。
這時有位大佬提出一個非常有價值的建議,他懷疑df -h看到的磁碟空間並不準確, 比如虛擬機器上看到的剩餘磁碟空間還有100GB,但實際虛擬機器所在宿主機物理磁碟只有2GB可用空間,這時超過2GB的資料肯定是無法寫入的,建議使用cp命令複製一個大檔案到資料檔案目錄,經測試檔案確實無法寫入,提示:No space left on device ,顯然df -h看到可用空間,遠遠小於實際可用空間。
但這位朋友反饋,並沒有使用虛擬機器,使用的是 物理機,那麼還有什麼原因會導致df -h資料不準確呢,之前遇到過nas儲存檢視空間使用率不準確。還有帶有壓縮功能的儲存不準確,但這種情況大多數實際可用空間大於df -h顯示的可用空間。
這時另一個大佬提出了一個非常重要的概念:“ 精簡卷”,最終也定位到確實是這個精簡卷導致的問題,很顯然,又觸到我的知識盲區了。
到底什麼是“精簡卷呢”?
redhat官網有詳細介紹,相關連結如下:
https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/creating-and-managing-thin-provisioned-volumes_configuring-and-managing-logical-volumes
第 11 章 建立和管理精簡配置的卷(精簡卷)
Red Hat Enterprise Linux 支援精簡配置的快照卷和邏輯卷。
邏輯卷和快照卷可以是精簡配置的:
使用精簡配置的邏輯卷,您可以建立大於可用物理儲存的邏輯卷。
使用精簡配置的快照卷,您可以在同一資料卷中儲存更多虛擬裝置。
11.1. 精簡配置概述
很多現代儲存堆疊現在提供在密集配置和精簡配置之間進行選擇的能力:
密集配置提供了塊儲存的傳統行為,其中塊的分配與其實際用途無關。
精簡配置允許置備更大的塊儲存池,其大小可能大於儲存資料的物理裝置,從而導致過度配置。
過度置備可能是因為單個塊在實際使用之前沒有被分配。
如果您有多個共享同一池的精簡置備裝置,那麼這些裝置可以是過度配置的。
透過使用精簡配置,您可以超額使用物理儲存,且可以管理稱為精簡池的可用空間池。
當應用程式需要時,您可以將這個精簡池分配給任意數量的裝置。
當需要有效分配儲存空間時,您可以動態擴充套件精簡池。
例如,如果 10 個使用者的每個使用者都為他們的應用程式請求一個 100GB 的檔案系統,那麼您可以為每個使用者建立一個 100GB 的檔案系統,但其由較少的實際儲存支援,僅在需要時使用。
注意
在使用精簡配置時,監控儲存池,並在可用物理空間耗盡時新增更多容量是非常重要的。
以下是使用精簡配置的裝置的一些優點:
1.您可以建立大於可用物理儲存的邏輯卷。
2.您可以將更多的虛擬裝置儲存在相同的資料卷中。
3.您可以建立邏輯上可自動增長的檔案系統,以支援資料需求,並將未使用的塊返回給池,以供池中的任意檔案系統使用。
以下是使用精簡配置的裝置的潛在缺陷:
1.精簡配置的卷存在耗盡可用物理儲存的固有風險。
如果過度配置了底層儲存,您可能會因為缺少可用物理儲存而導致停機。
例如,如果您建立了 10T 的精簡配置的儲存,而只有 1T 的物理儲存來支援,則卷將在 1T 耗盡後不可用或不可寫。
2.如果卷在精簡配置的裝置後沒有向層傳送丟棄,那麼對使用情況的統計將不準確。
例如,在不使用 -o discard mount 選項的情況下放置檔案系統,且不在精簡配置的裝置之上定期執行 fstrim,則永遠不會不分配之前使用的儲存。
在這種情況下,隨著時間的推移,即使沒有真正使用它,您最終都會使用全部的置備量。
您必須監控邏輯和物理使用情況,以便不會用盡可用的物理空間。
在帶有快照的檔案系統上,寫時複製(CoW)操作可能會較慢。
資料塊可以在多個檔案系統之間混合,導致底層儲存的隨機訪問限制,即使它沒有向終端使用者展示那種方式。
精簡卷測試過程:
測試資料庫:Oracle 11.2.0.4.0作業系統:Red Hat Enterprise Linux Server release 7.5 (Maipo)
新增加一個2GB大小的磁碟
[root@cjc-db-01 ~]# lsblk sdb 8:16 0 2G 0 disk
[root@cjc-db-01 ~]# fdisk -l Disk /dev/sdb: 2147 MB, 2147483648 bytes, 4194304 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytes
建立PV
pvcreate /dev/sdb Physical volume "/dev/sdb" successfully created.
建立VG
vgcreate vg_chenjch /dev/sdb Volume group "vg_chenjch" successfully created
建立精簡池
[root@cjc-db-01 ~]# lvcreate -L 1G -T vg_chenjch/mythinpool Thin pool volume with chunk size 64.00 KiB can address at most 15.81 TiB of data. Logical volume "mythinpool" created.
建立精簡卷:
[root@cjc-db-01 ~]# lvcreate -V 100G -T vg_chenjch/mythinpool -n thinvolume WARNING: Sum of all thin volume sizes (100.00 GiB) exceeds the size of thin pool vg_chenjch/mythinpool and the size of whole volume group (<2.00 GiB). WARNING: You have not turned on protection against thin pools running out of space. WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full. Logical volume "thinvolume" created.
可以看到,總磁碟大小2GB,分配1GB給VG卷組,從VG中可以建立100GB的LV,遠大於磁碟和VG大小,從而導致了df -h資料不準確。
檢視建立的精簡池和精簡卷
[root@cjc-db-01 soft]# lvs -a -o +devices LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices swap ol -wi-ao---- 2.00g /dev/sda2(0) [lvol0_pmspare] vg_chenjch ewi------- 4.00m /dev/sdb(0) mythinpool vg_chenjch twi-aotzM- 1.00g 100.00 13.67 mythinpool_tdata(0) [mythinpool_tdata] vg_chenjch Twi-ao---- 1.00g /dev/sdb(1) [mythinpool_tmeta] vg_chenjch ewi-ao---- 4.00m /dev/sdb(257) thinvolume vg_chenjch Vwi-aotz-- 100.00g mythinpool 1.00 root vg_cjc -wi-ao---- <46.99g /dev/sda3(0)
格式化
[root@cjc-db-01 ~]# mkfs -t xfs /dev/mapper/vg_chenjch-thinvolume meta-data=/dev/mapper/vg_chenjch-thinvolume isize=256 agcount=16, agsize=1638400 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=16 swidth=16 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=1log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=16 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0
掛載
[root@cjc-db-01 ~]# mkdir /oradata [root@cjc-db-01 ~]# mount /dev/mapper/vg_chenjch-thinvolume /oradata
檢視可用空間,顯示100G。
[root@cjc-db-01 ~]# df -h /oradata/Filesystem Size Used Avail Use% Mounted on/dev/mapper/vg_chenjch-thinvolume 100G 33M 100G 1% /oradata
授權
[root@cjc-db-01 ~]# chown oracle:oinstall /oradata
建立表空間,資料檔案大小800MB
SQL> create tablespace cjc datafile '/oradata/cjc_tbs01.dbf' size 800M;Tablespace created.
新增資料檔案,在新增一個800MB資料檔案
由於1600MB大於1GB,所以新增失敗。
SQL> alter tablespace cjc add datafile '/oradata/cjc_tbs02.dbf' size 800M; alter tablespace cjc add datafile '/oradata/cjc_tbs02.dbf' size 800M *ERROR at line 1:ORA-01119: error in creating database file '/oradata/cjc_tbs02.dbf' ORA-27052: unable to flush file dataLinux-x86_64 Error: 5: Input/output errorAdditional information: 1
錯誤號和那位朋友遇到的不同,他的錯誤號是ORA-19502、ORA-27072,我模擬出的錯誤號是ORA-01119,ORA-27052,不清楚是因為資料庫版本還是其他什麼原因導致錯誤號不一樣,簡單看下相關錯誤號說明。
[oracle@cjc-db-01 oradata]$ oerr ora 0111901119, 00000, "error in creating database file '%s'"// *Cause: Usually due to not having enough space on the device.// *Action:[oracle@cjc-db-01 oradata]$ oerr ora 2705227052, 00000, "unable to flush file data"// *Cause: fsync system call returned error, additional information// indicates which function encountered the error// *Action: check errno
[oracle@cjc-db-01 oradata]$ oerr ora 1950219502, 00000, "write error on file \"%s\", block number %s (block size=%s)"// *Cause: write error on output file// *Action: check the file[oracle@cjc-db-01 oradata]$ oerr ora 2707227072, 00000, "File I/O error"// *Cause: read/write/readv/writev system call returned error, additional// information indicates starting block number of I/O// *Action: check errno
雖然
df -h顯示還有大量可用空間,由於精簡卷的原因,
可用空間
並不準確。
[root@cjc-db-01 soft]# df -h/oradata/Filesystem Size Used Avail Use% Mounted on/dev/mapper/vg_chenjch-thinvolume 100G 833M 100G 1% /oradata
為了少踩坑,請遠離“精簡卷”。
更多內容,請關注微信公眾號"IT小Chen"
###chenjuchao 20240120###
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/29785807/viewspace-3004540/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle:容器資料庫簡介Oracle資料庫
- ORACLE資料庫簡介(轉)Oracle資料庫
- Flyway, 資料庫Schema管理利器資料庫
- 【LOG】Oracle資料庫清理日誌、跟蹤檔案利器Oracle資料庫
- Oracle資料庫效能障礙分析利器:SYSTEMSTATE DUMP介紹Oracle資料庫
- 簡述oracle資料庫結構Oracle資料庫
- FlashText:語料庫資料快速清理利器
- Oracle - 資料庫的組成簡介Oracle資料庫
- 大資料下的運營利器:精準推送系統大資料
- 資料庫同步利器 otter 雙A同步配置資料庫
- Docker資料管理(資料卷+資料卷容器)Docker
- 第1章 Oracle資料庫簡介-DBMSOracle資料庫
- 第1章 Oracle資料庫簡介-RMOracle資料庫
- 調查問卷資料庫設計資料庫
- SQL 遷移資料庫至ORACLE簡易方法SQL資料庫Oracle
- Centos8中建立LVM精簡邏輯卷CentOSLVM
- Oracle角色精簡總結Oracle
- 挖坑
- Oracle 資料庫Oracle資料庫
- 資料庫治理利器:動態讀寫分離資料庫
- oracle 10g建立資料庫鏈的簡化Oracle 10g資料庫
- Oracle資料庫的閃回查詢功能簡介Oracle資料庫
- Oracle23ai 資料庫的簡單驗證OracleAI資料庫
- 精PHP與MYSQL資料庫連線PHPMySql資料庫
- zt_oracle block資料塊精講OracleBloC
- 資料庫-oracle-資料庫遷移資料庫Oracle
- Docker 資料卷,資料卷容器詳細介紹Docker
- docker資料卷概念以及刪除資料卷方法Docker
- Zabbix系統MySQL資料庫分割槽表的設定--精簡說明MySql資料庫
- 容器資料卷
- Docker資料卷Docker
- 資料同步利器 - canal
- 統信作業系統下資料庫管理利器作業系統資料庫
- oracle資料庫卡頓Oracle資料庫
- oracle資料庫SCNOracle資料庫
- Oracle資料庫效能Oracle資料庫
- 理解ORACLE資料庫Oracle資料庫
- Oracle資料庫管理Oracle資料庫