Oracle

癥狀：c/s程式本來運行正常，一次重裝系統，重裝oracle用戶端後，insert日期格式資料，出現題目中錯誤。 解決辦法：Oracle時間格式討論在網上看見不少oracle新學者對oracle的時間格式很煩，經常是設計了一個帶時間欄位的表之後，向表插入資料失敗。回想起自己剛開始學習oracle時，也對這個時間格式摸不著頭腦，雖然是小小的問題，高手們不屑於討論，但對初學者來講，這也是一個不大不小的坎，沒找到門路的話，

使用者的最大串連數查看該使用者的最大串連數select profile from dba_users where username='APP_TEST';select * from dba_profiles where profile='PF_APP_TEST' and resource_name='SESSIONS_PER_USER';查看該使用者當前的串連數select count(*) from v$session where username='

高水位的影響及大並發插入的效能問題一、資料區塊的插入時尋找可用塊的規則總結：高水位與低高水位：低高水位與高水位之間存在的資料區塊的狀態可能是未格式化或格式的。低高水位以下的是格式化了的，可以被使用。1.首先，插入一條資料，只會使用高水位以下的資料區塊。高水點的位置：L1塊所包含資料區塊的邊界，要麼是區的邊界2.第一次插入一行資料，格式化塊數？並沒有一個一定的數值，從DUMP

solaris x86安裝ORACLE 11.2.0.3軟體時因SWAP不足報錯： INFO: ld: fatal: mmap anon failed1.ORACLE軟體安裝到86%時報錯，圖忘截了。日誌如下：/oracle/u01/app/oracle/product/11.2.0/INFO: db_1/lib/sysliblist` -R /opt/SUNWcluster/lib -R/export/home/oracle/u01/app/oracle/product/11.2.0/db_1

Oracle Database 11g 預設具備一個系統定義的Moving Window Baseline，該基準對應於 AWR 保留期中的所有 AWR 資料。僅可存在一個Moving Window Baseline。系統定義的Moving Window Baseline認大小為當前的AWR保留期，即預設為八天。如果要增大Moving Window Baseline，首先需要相應增大AWR保留期。AWR保留期和系統定義的Moving Window

1.1.1. RMAN-06556日期：2014-05-21 16:33環境：測試環境【情景描述】使用RMAN進行了全庫備份，但是在進行不完全恢複的時候遇到報錯，提示某個資料檔案必須從比給出的SCN更早的備份中恢複。【報錯資訊】備份資料庫：RMAN> backup database plus archivelog;Starting backup at 2014-05-21 15:02:13current log archived......Finished backup at 2014-05-2

1．參數檔案的設定(1)查看動態參數檔案select * from sys.props$ wherename='NLS_CHARACTERSET';動態參數檔案：spfile:其中的動態參數修改能夠立即生效(2)修改動態參數alter system set 參數=值 scope=<memory><spfile><both>#memory 僅當前生效；（適用於動態參數）#spfile: 當前不生效；重啟後生效；（適用於動態，靜態參數）#both:

查看當前session的sid和serial#:SYS@ORCL>select sid,serial#,status from v$session where sid=userenv('sid');    SID    SERIAL# STATUS---------- ---------- --------     89          3

DATAGUARD配置如下：PROD為主庫，SBDB為備庫日誌組1-3組為redolog file，4-6組為standby log在建立standby log後主庫關庫，使用冷備tar包將資料轉送到備庫進行的恢複。DG配置完成之後，啟動備庫之後，備庫alert日誌報錯如下：Errors in file /u01/app/oracle/admin/SBDB/udump/sbdb_rfs_14903.trc:ORA-00313: open failed for members of log

概念描敘ORACLE資料庫有國家字元集（national character set）與資料庫字元集(database character

called an Oracle Local Registry (OLR）： each node in a cluster has a local registry for node-specific resources測試一：類比olr異常丟失的情況：這裡首先將olr renam[root@vmrac2 cdata]# mv vmrac2.olr vmrac2.olr.bak然後嘗試去啟動crs[root@vmrac2 cdata]# crsctl start crsCRS-4124:

環境聲明：WIN7 64位ORACLE 64位Grid Infra 64位安裝之前請保證環境未安裝過oracle資料庫或者已經徹底卸載第一步：建立虛擬裸盤在D盤下建立asmdisks目錄進入電腦管理->儲存->磁碟管理，選擇一個有足夠空閑空間的盤，右鍵->壓縮卷，壓縮出一塊空間用於建立裸盤（最好有4G，建立四個裸盤，每個1G，有空間多建立幾個也行），選擇壓縮出來的空間建立卷，在建立過程中選擇掛到D:\asmdisks目錄。 第二步：安裝Grid

預設情況下，AWR的資訊每隔一個小時收集一次AWR資訊，並保留7天。這些資料存放在SYSAUX資料表空間中，可能會導致SYSAUX資料表空間不足，如果SYSAUX空間嚴重不足，將會在alter日誌報ORA-1683和ORA-1688錯誤，建議修改為每隔4小時收集一次並保留3天的資料。現象描述：版本：oracle 11.0.7oracle日常檢查中發現alter日誌報如下錯誤：ORA-1683: unable to extend index SYS.WRH$_LATCH_PK

Oracle 11g預設安裝資料庫啟動了audit功能，導致oracle不斷累積sys.aud$表及相關索引資料量增加；如果導致資料表空間滿了，在alert日誌中將會報ORA-1654: unable to extend index SYS....錯誤。如果不用到審計功能，建議關閉審計。處理過程：1、用oracle使用者登入到資料庫伺服器，執行：sqlplus / as sysdba2、取消audit，將初始化參數audit_trail設定為NONEalter system set audit_

今天在往一個壓縮表增加一個欄位可以增加成功，但在刪除的時候報了個ORA-39726 unsupported add/drop column operation on compressed tables的錯誤。錯誤是不能對壓縮表增加或刪除欄位，奇怪的可以增加，但是不能刪除。即使將表MOVE為非壓縮表也還是不可以刪除。最後終於找到了一種方法那就是先將該欄位設定為UNUSED，然後在刪除UNUSED欄位即可。例如：ALTER TABLE test SET UNUSED COLUMN

今天一台測試機器的oracle服務端，在測試人員建庫的時候字元集設定成了WE8MSWIN1252字元集，導致無法儲存俄文等其他國家語言。於是我建議測試將字元集修改為AL32UTF8。首先查看服務端字元集select * from v$nls_parameters where parameter = 'NLS_CHARACTERSET'NLS_CHARACTERSET WE8MSWIN1252然後用sys使用者進行修改#sqlplus "/as

相對物理Standby，邏輯Standby的管理要複雜一點點。這個就是管理一個半資料庫和管理兩個資料庫的差異（假設Data

1.DBA_LOGSTDBY_EVENTS可以把該視圖看成邏輯Standby動作記錄，因此如果發生了錯誤，可以通過該視圖查看近期邏輯Standby都做了些什麼。預設情況下，該視圖只保留最近100條事件的記錄（可以通過相關過程修改儲存的記錄條數）。例如：SQL> SELECT EVENT_TIME,STATUS,EVENT FROM DBA_LOGSTDBY_EVENTSORDER BY EVENT_TIMESTAMP;EVENT_TIM STATUS    

LOB大對象處理： 主要是用來儲存大量資料的資料庫欄位，最大可以儲存4G位元組的非結構化資料。 主要介紹字元類型和二進位檔案類型LOB資料的儲存，單獨介紹二進位類型LOB資料的儲存。一、Oracle中的LOB資料類型分類1、按儲存資料的類型分：①字元類型：CLOB:儲存大量 單位元組 字元資料。NLOB:儲存定寬 多位元組

資料庫市場的瞬息萬變由此可見：MySQL首席執行官Martin Mickos先是稱呼甲骨文公司的某項產品為“殘廢軟體”（crippleware），幾分鐘後又盛讚該公司為年度最佳夥伴。 Mickos 26日在MySQL使用者會議的演說中力捧甲骨文，卻又嚴詞批評其產品。如此反覆的原因在於，MySQL一方面仰賴甲骨文2005年收購的InnoDB軟體，另一方面，甲骨文和IBM為反制MySQL在資料庫市場的竄起，紛紛推出免費的入門級產品。