Oracle

首先查看一下v$session都存在哪些列SYS@ORCL>desc v$sessionName                                      Null?    Type----------------------------------------- ----

首先查看v$process都存在哪些列SYS@ORCL>desc v$processName                                      Null?    Type----------------------------------------- ---

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

一、共用伺服器模式工作機制：共用伺服器模式（SHARED SERVER,也叫MTS Multi-Threaded Server）：資料庫啟動之後比專用伺服器模式會多出兩種進程，一種是調度進程（dispatcher），一種是共用伺服器處理序。來自用戶端的請求會被dispatcher接受，然後dispatcher將請求置入Request隊列。閒置Server Process會按照request隊列開始處理隊列中的請求。處理過後的結果放入Response隊列中。

今天配置完共用伺服器模式之後發現登入過程中報錯ORA-12523，排查錯誤之後發現是靜態監聽惹的禍。本機之上有兩個監聽，一個靜態監聽1521連接埠，一個動態監聽1526連接埠。LISTENER=(DESCRIPTION=  (ADDRESS_LIST=    (ADDRESS=(PROTOCOL=tcp)(HOST=jp)(PORT=1521))  

對於oracle中的堆表，我們可以通過oracle內建的ROWID偽列得到對應行記錄所在的ROWID的值（注意，這個ROWID只是一個偽列，實際的塊中並不存在該列）。然後我們可以通過DBMS_ROWID包中的相關方法來通過ROWID偽列來定位對應資料行的實際實體儲存體物理地址。dbms_rowid.rowid_relative_fno：定位該資料行所在的資料檔案dbms_rowid.rowid_block_number：定位該資料行在資料檔案的第多少個塊dbms_rowid.rowid_row_

之前不是很明白加密角色的作用，今天查了一些資料發現加密角色可以以非default角色授予一個使用者，只有在需要的時候再進行啟用。一些比較敏感的許可權在平時的工作中基本用不到，為了防止誤操作完全可以把這些許可權單獨授予一個角色，只有在有需要的時候進行啟用。還有就是對同一使用者組的使用者可以有一些許可權上的分割，不知道加密角色密碼的人無法啟用這方面的許可權。下面進行實驗：首先建立兩個角色r_cs和r_select，並且授予相應的許可權：SYS@ORCL>create role

原來對於索引的認識只知道索引可以基於一個或者多個列，B-Tree索引不包含null，但有些情況下我們又需要通過where 列名 is null來尋找一些資料，這時候資料庫由於沒辦法使用索引就會使用全表掃描，導致執行效率低下，這時候我們可以通過使用含常數的複合索引來解決這個問題。下面開始進行實驗：首先建立測試表SYS@ORCL>create table test_objects nologging as select rownum id,a.* from dba_objects a

SCHEDULER使用詳解：建立SCHEDULER：BEGINsys.dbms_scheduler.create_schedule(repeat_interval => 'FREQ=DAILY;BYHOUR=15;BYMINUTE=0;BYSECOND=0',start_date => systimestamp at time zone '+8:00',end_date => to_timestamp_tz('2014-03-15 +8:00', 'YYYY-MM-DD

基於scheduler的job的設定，基本的建立指令碼：sys.dbms_scheduler.create_job(job_name => '"SYS"."REBUILD_JOB1"',program_name => '"SYS"."EMP_IND_REBUILD"',schedule_name =>

個人實驗的時候有時會用到一些大表，在此分享用dba_objects來建立測試大表的方法：首先建立測試表SYS@ORCL>create table test nologging as select rownum id,a.* from dba_objects a where 1=2;SYS@ORCL>declare l_cnt number; l_rows number:=&1; begin insert /*+

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

癥狀描述：在linux下使用sqlplus sys/oracle@prod as sysdba登入非常慢，大概需要十幾秒才能登入成功，使用sqlplus / as sysdba 登入資料庫速度很快，秒登。使用sqlplus sys/oracle@prod as sysdba登入會卡在下面這個位置十幾秒：[oracle@jp admin]$ sqlplus sys/oracle@prodSQL*Plus: Release 10.2.0.1.0 - Production on Wed Mar 26

普通表線上重定義為分區表過程中報錯，數值範圍超過了分區限制大小，那麼想要重新對錶進行線上重定義需要經過哪些步驟呢？這個例子記錄了處理過程：SALES@ORCL>exec dbms_redefinition.start_redef_table('SALES', 'SALES', 'SALES_P');BEGIN dbms_redefinition.start_redef_table('SALES', 'SALES', 'SALES_P'); END;*ERROR at line 1:ORA-

最近做了一個項目，通過VC odbc訪問oracle資料庫，在我電腦上可以正常運行，在其他電腦上運行不了，原因是沒有oracle odbc驅動，無法配置oracle資料來源。網上的博文大都是安裝oracle用戶端來解決的。我想就是一個小程式，沒必要安裝用戶端吧，參照網上博文並訪問了oracle網址，於是有了這篇文章。1、下載odbc驅動需要下載兩個東西instantclient-basiclite-nt-12.1.0.1.0.zipinstantclient-odbc-nt-12.1.0.1.0

1. 保留七天只保留七天的備份是這樣設定的RMAN> connect target/connected to target database: DBSID (DBID=3100778490)RMAN> configure retention policy to recovery window of 7 days;2. 備份指令碼vi /root/rmanbak.sh#! /bin/bashsu - oracle <<!rman target

刪除crs1. 停止資源：關閉crs資源：crsctl stop resources關閉crs:       crsctl stop crs2. 使用指令碼：兩個節點root.delete.sh, rootdeinstall.sh3. 刪除啟動項：rm/etc/oracle/*rm -f/etc/init.d/init.cssdrm -f /etc/init.d/init.crsrm -f/etc/init.d/init.crsdrm

(1)查看庫資訊select * from v$version(2)查看字元集select * from sys.props$ wherename='NLS_CHARACTERSET';1．  進程查看l  資料庫寫進程：oracle    2438    1  0 01:39 ?        00:00:00 ora_dbw0_EDWPRDl  日誌寫進程：

問題這兩天剛將PLSQL與Oracle配置好，可是在PLSQL中插入資料時，出現一個問題，PLSQL中的表裡無法顯示中文，中文無法儲存、無法輸出，中文在表中顯示問號，如圖：原因經過一番查證，發現問題的源頭不是出現在PLSQL上，而是出現在我們的Oracle上，由於我們的Oracle資料庫裡的字元集不支援中文導致的，既然知道了原因，就好辦了，我們就配置我們的Oracle字元集，讓他支援中文。解決辦法我的Oracle是11g版本的，下面以我的為例，為大家講解下設定的過程。步驟一開始-運行-輸入reg

一、概述前一段時間，有一個DBA朋友在完成重建表(rename)工作後，第二天早上業務無法正常運行，出現資料無法插入的限制和錯誤，後來分析才發現，錯誤的原因是使用rename方式重建表以後，其它引用這個表的外鍵約束指向沒有重新定義到這個重建的新表中，從而導致這些表在插入新資料時，違反資料完整性約束，導致資料無法正常插入。影響了業務大概有1個多小時，真是一次血淋淋的教訓啊。使用rename方式重建表是我們日常DBA維護工作中經常使用的一種方法，因為CTAS+rename這種配合方式，非常實用和高效