在Oracle數據庫中，提供了一套默認的用戶操作環境。如用戶查詢的時候，從數據庫中一次提取的行數;列之間的分隔符;每行顯示的最大寬度;每頁默認顯示的行數等等。這些都是靠數據庫的環境變量來控制。這些參數雖然是Oracle系統推薦的，但是，往往不符合數據庫管理的要求。因為我們工作一段時間以來，已經養成了自己的一套工作習慣。所以，我們希望每次更換一個Oracle運行環境之後，數據庫都能夠提供一個我們熟悉的運行環境。這無疑可以提高我們工作的興趣與效率。
為此，我們就需要手工的更改Oracle的環境變量，以達到我們的要求。筆者下面結合自己的工作習慣，談談一些常用的環境變量的設置。相信憑借這些參數，可以給各位數據庫管理員提供一個舒適的“工作環境”。
環境變量一：設置列之間的分隔符
平時在SQL*Plus工具中，利用SQL語句查詢的話，其列之間默認情況下是利用空格來進行區分的。但是，筆者覺得這個區分不夠明顯。有時候，經常會看錯。當數據多的時候，還會給人一種“暈車”的感覺。故筆者往往一開始，就會更改這個默認設置。筆者喜歡利用“|”符號來對列之間進行區分。
如通過如下設置，就可以讓顯示結果以“|”符號來區分各個列。SET COLSEP |。通過這條語句，就可以對數據庫的環境變量進行設置。最後的運行結果如下。利用|這個符號來對列進行區分，看起來就會清楚的多。字段之間就會弄混。
環境變量二：設置是否自動遞交
在Oracle數據庫中有事務控制的概念。也就是說，當我們利用Update語句更新數據庫的某些內容的時候，默認情況下，執行這條語句後不會馬上就對數據庫文件中的數據進行更改。在同一個對話中，查詢的話，其顯示的結果已經是更改後的結果。但是，若先注銷這個對話，在重新連接、查詢的話，其顯示的結果仍然是修改之前的結果。其更改的內容沒有被保存。這主要是因為這個更新的事務沒有被遞交上去。
根據Oracle數據庫的設置，默認情況下，事務是不主動遞交的。而是需要用戶手工的輸入commmit命令，來遞交相關的事務。一般來說，DML語句都需要用戶手工的遞交事務才能夠其作用。
這個設計本來是為了給數據庫管理員有一個緩沖的機會;同時，也是給終端用戶一個確認數據是否准確的一個機會。另外，利用這種機制，也可以幫助數據庫管理員很容易的實現回退機制。
如現在在一個進銷存管理系統中，需要把物料從一個倉庫中轉移到另一個倉庫裡去。此時，就需要通過事務來進行控制。從一個倉庫中把物料數量減少，另一個倉庫中增加。但是，若在另一個倉庫中增加數量的操作因為某種原因失敗，則就需要對“某個倉庫中數量減少”這個事務進行回退。也就是說，不向數據庫遞交這個事務。通過這種機智，就可以輕松的實現各個作業之間數據的一致性。
不過，在數據庫設計的時候，手工遞交相關事務，筆者認為有中畫蛇添足的感覺。筆者在數據庫前期開發的時候，往往會改變這個默認設置。筆者希望讓系統自動遞交這個事務。然後，再後台測試的時候，再把這個環境變量改回來。
如相讓數據庫自動遞交相關事務的話，則可以利用SET AUTOCOMMIT ON命令來實現。如此的話，每次執行DML語句，數據庫就會自動遞交這個命令。而不會每次都要用戶手工輸入COMMIT命令才遞交相關的事務。不過，在數據庫設計完成後，需要把這個環境變量改回來，改成手工遞交事務。
環境變量三：設置每行的寬度
這是一個很重要環境變量。在Oracle數據庫中，如果行數據長度超過我們設置的最大長度時，就會自動換行。可是數據查詢的結果是按列來顯示，但是若自動換行的話，則其結果看起來就會很糟糕。默認情況下，數據庫的默認行寬度為80。
筆者認為這個寬度太小。筆者喜歡采用比較大的寬度。筆者寧願利用滑條滾動來查看數據，也不原意讓其自動分行影響顯示結果。如下圖。如果行寬度不夠的話，就會按如下的方式顯示。這個結果看起來的話，十個人中有十個人會看得眼花。
故筆者在一開始，就會把這個行設置的足夠的寬，如可以設置為200。這可以有效的避免因為換行所造成的結果顯示混亂問題。
環境變量四：字段名與標題之間的分隔線
從上面查詢結果的截圖中，我們可以看到，默認情況下，字段名與查詢結果是用下劃線進行區別的。不過筆者個人也比較討厭這種格式。覺得這種單下劃線讓人看得不夠清楚。很容易跟字段中正常的下劃線搞混。
筆者喜歡利用米字符(*)來進行隔離。在數據庫中，可以利用Underline參數來設置這個字段名與字段內容的分隔符。如下圖中，就是筆者設置後顯示的結果。數據庫管理員可以根據自己的操作習慣，設置合理的分隔符。
環境變量來控制。如只要把Heading這個變量設置為OFF，即可。如此的話，每次查詢的結果，只有列的結果，而沒有列的標題。不過筆者不喜歡這種設置。
以上的這些環境變量設置只有在當前的會話中生效。如果數據庫管理員退出會話後，這些用戶設置的環境變量就會失效。當用戶下次連接到數據庫查詢的時候，數據庫仍然采用的是其默認的環境變量，而不是用戶上次配置過後的環境變量。顯然，若讓我們數據庫管理員每次登錄數據庫都一一的去配置環境變量的話，工作量太大，估計沒有多少人會願意做這些重復性的工作。而寧願接受數據庫不怎麼人性化的默認設置。
其實，在Oracle數據庫中，我們可以把自己配置的環境變量保存下來。如在第一次配置好環境變量之後，數據庫管理員可以利用Store命令，將自己定義好的環境變量保存到一個腳本文件中。若在這個命令中，不指定具體保存路徑的話，則數據庫默認保存在Oracle的安裝目錄下。筆者往往會為其指定一個保存路徑，因為這個環境變量筆者以後需要重復用到。到把這些文件保存為腳本文件後，下次數據庫管理員需要初始化環境變量的時候，就可以利用Start命令，來執行這個腳本文件。
這種方式雖然比用戶手工的輸入一個個環境變量要方便的多。但是，用戶每次登錄SQL*Plus環境都需要手工的運行這個腳本文件，顯然也比較麻煩。我們希望能夠在每次登錄這個環境之後，系統會自動執行這個腳本文件;而不是每次去手工的執行。要實現這個需求，也不是什麼難事。如果數據庫管理員希望每次啟動SQL*Plus工具的時候，都自動應用我們指定的環境變量，則只需要改變系統默認的環境變量腳本文件。也就是說，SQL*Plus在啟動的時候，會自動的去運行其系統目錄下的腳本文件。若我們把這個環境變量的腳本文件進行修改，則就可以把我們喜歡的操作環境指定為默認設置。系統默認的環境將變量腳本文件一般存放在\admin\目錄下面。數據庫管理員先把自己的配置保存後，覆蓋這個文件即可。
總之，這個環境變量跟用戶的最終使用沒什麼直接的關系。主要是為了方便我們數據庫工程師的工作。把它設置成為我們熟悉的環境，可以提高我們的工作效率。
