當前位置:首頁 » 數據倉庫 » 資料庫系統進程
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

資料庫系統進程

發布時間: 2022-08-29 01:54:21

『壹』 資料庫系統包括七個層次的內容

第7層 應用層:OSI中的最高層。為特定類型的網路應用提供了訪問OSI環境的手段。應用層確定進程之間通信的性質,以滿足用戶的需要。應用層不僅要提供應用進程所需要的信息交換和遠程操作,而且還要作為應用進程的用戶代理,來完成一些為進行信息交換所必需的功能。它包括:文件傳送訪問和管理FTAM、虛擬終端VT、事務處理TP、遠程資料庫訪問RDA、製造報文規范MMS、目錄服務DS等協議;
第6層 表示層:主要用於處理兩個通信系統中交換信息的表示方式。為上層用戶解決用戶信息的語法問題。它包括數據格式交換、數據加密與解密、數據壓縮與恢復等功能;
第5層 會話層:—在兩個節點之間建立端連接。為端系統的應用程序之間提供了對話控制機制。此服務包括建立連接是以全雙工還是以半雙工的方式進行設置,盡管可以在層4中處理雙工方式 ;
第4層 傳輸層:—常規數據遞送-面向連接或無連接。為會話層用戶提供一個端到端的可靠、透明和優化的數據傳輸服務機制。包括全雙工或半雙工、流控制和錯誤恢復服務;
第3層 網路層:—本層通過定址來建立兩個節點之間的連接,為源端的運輸層送來的分組,選擇合適的路由和交換節點,正確無誤地按照地址傳送給目的端的運輸層。它包括通過互連網路來路由和中繼數據 ;
第2層 數據鏈路層:—在此層將數據分幀,並處理流控制。屏蔽物理層,為網路層提供一個數據鏈路的連接,在一條有可能出差錯的物理連接上,進行幾乎無差錯的數據傳輸。本層指定拓撲結構並提供硬體定址;
第1層 物理層:處於OSI參考模型的最底層。物理層的主要功能是利用物理傳輸介質為數據鏈路層提供物理連接,以便透明的傳送比特流。

數據發送時,從第七層傳到第一層,接收數據則相反。

『貳』 為什麼資料庫系統要採用並發控制

並發(concurrent)和並行(parallel)這兩個概念,在資料庫系統的資料中經常出現,然而有關它們的定義和區別卻沒有明確的說法。這里,我們根據這兩個概念在資料中的使用,對它們的不同做一個說明。

並發是指多個任務的同時執行,任務與任務之間沒有聯系。由於資料庫系統要同時為許多用戶提供服務,每個用戶都可以發出自己的訪問請求,一個請求就是一個任務。在一個時間點,資料庫系統可能要同時處理多個任務。因此,資料庫系統一定要具備並發處理能力。

並行是指將一個任務劃分為多個子任務,這些子任務同時執行。在所有子任務處理完成後,將它們的結果進行合並,就得到該任務的最終處理結果。在資料庫系統中,如果要執行一個大的數據查詢,為了提高速度、降低響應時間,用戶可以通過系統配置或者在命令中,要求對該大數據量查詢進行並行處理,將該查詢劃分成多個子查詢。這些子查詢同時執行,最後系統將所有子查詢的處理結果進行合並,作為該查詢處理的最終結果。現有的大型資料庫系統都支持並行處理。

需要說明的是,並發和並行與資料庫系統採用多進程還是多線程體系結構無關。對採用多進程結構的資料庫系統,所有的任務、子任務通過進程來處理;而對採用多線程結構的資料庫系統,這些工作是由線程來完成。

資料庫系統的並發控制,涉及到任務的調度、數據的一致性及可靠性等,而資料庫系統的並行處理,主要涉及任務的處理速度、系統性能等方面。

『叄』 oracle資料庫經常會出現佔用cpu100%的進程,然後系統就掛了,怎麼找出引起這種故障的sql語句

在故障發生時,嘗試用下面的語句抓取資料庫引起故障的點。

/*********************************************************************************************/
在oracle中監控死鎖
/*********************************************************************************************/
SELECT sn.username,
m.SID,
sn.SERIAL#,
m.TYPE,
DECODE(m.lmode,
0,
'None',
1,
'Null',
2,
'Row Share',
3,
'Row Excl.',
4,
'Share',
5,
'S/Row Excl.',
6,
'Exclusive',
lmode,
LTRIM(TO_CHAR(lmode, '990'))) lmode,
DECODE(m.request,
0,
'None',
1,
'Null',
2,
'Row Share',
3,
'Row Excl.',
4,
'Share',
5,
'S/Row Excl.',
6,
'Exclusive',
request,
LTRIM(TO_CHAR(m.request, '990'))) request,
m.id1,
m.id2
FROM v$session sn, v$lock m
WHERE (sn.SID = m.SID AND m.request != 0) --存在鎖請求,即被阻塞
OR (sn.SID = m.SID --不存在鎖請求,但是鎖定的對象被其他會話請求鎖定
AND m.request = 0 AND lmode != 4 AND
(id1, id2) IN (SELECT s.id1, s.id2
FROM v$lock s
WHERE request != 0
AND s.id1 = m.id1
AND s.id2 = m.id2))
ORDER BY id1, id2, m.request;

/*********************************************************************************************/
定位引起oracle死鎖的sql
/*********************************************************************************************/

select sql_text from v$sql where hash_value in
(select sql_hash_value from v$session where sid in
(select session_id from v$locked_object))

/*********************************************************************************************/
下面的SQL查詢可以用於確定鎖住資料庫對象的鎖:
/*********************************************************************************************/
select
c.owner,
c.object_name,
c.object_type,
b.sid,
b.serial#,
b.status,
b.osuser,
b.machine
from
v$locked_object a ,
v$session b,
dba_objects c
where
b.sid = a.session_id
and
a.object_id = c.object_id;

/*********************************************************************************************/
顯示哪些會話被鎖住
/*********************************************************************************************/
/* showlock.sql */
COLUMN o_name format a10
COLUMN lock_type format a20
COLUMN object_name format a15
SELECT RPAD (oracle_username, 10) o_name, session_id SID,
DECODE (locked_mode,
0, 'None',
1, 'Null',
2, 'Row share',
3, 'Row Execlusive',
4, 'Share',
5, 'Share Row Exclusive',
6, 'Exclusive'
) lock_type,
object_name, xisn, xidslot, xidsqn
FROM v$locked_object, all_objects
WHERE v$locked_object.object_id = all_objects.object_id;

/*********************************************************************************************/
顯示所有的TM和TX鎖
/*********************************************************************************************/
/* showalllock.sql */
SELECT SID, TYPE, id1, id2,
DECODE (lmode,
0, 'None',
1, 'Null',
2, 'Row share',
3, 'Row Exclusive',
4, 'Share',
5, 'Share Row Exclusive',
6, 'Exclusive'
) lock_type,
request, ctime, BLOCK
FROM v$lock
WHERE TYPE IN ('TX', 'TM');

/*********************************************************************************************/
在Oracle資料庫中,可以通過kill session的方式來終止一個進程,其基本語法結構為:
被kill掉的session,狀態會被標記為killed,Oracle會在該用戶下一次touch時清除該進程.
我們發現當一個session被kill掉以後,該session的paddr被修改,如果有多個session被kill,那麼多個session
的paddr都被更改為相同的進程地址:
/*********************************************************************************************/
alter system kill session 'sid,serial#' ;

/*********************************************************************************************/
在oracle中kill掉的進程有時還需要等待pmon回滾資料庫已經佔有的資源
有時候我們需要使用下面的腳本找出那些已經在oracle中kill掉的進程,在操作系統中在kill一次
/*********************************************************************************************/

select p.addr from v$process p where pid <> 1
minus
select s.paddr from v$session s;

$ kill -9 &paddr

『肆』 求查詢oracle資料庫dblink進程號方法,舉例說明!

1.通過SQL語句找到相應的SQL ID。
select sql_id,sql_text from v$sql where .....
2.通過SQL ID找到相應的物理進程地址
select sql_id, paddr from v$session where .....
3.通過相應的物理進程地址找到相應系統進程
select addr,spid from v$process where .....
或者通過dba_2pc_pending和dba_2pc_neighbors也可以查

『伍』 一個ORACLE資料庫中為什麼需要幾個歸檔進程一個不夠用嗎而且不同的歸檔進程求詳細點的分析。

簡單的說就是提高歸檔的效率,摘抄一段給你。

在默認情況下,一個常式只會啟動一個歸檔進程ARCH。當ARCH進程正在歸檔一個重做日誌文件時,任何其他的進程都不能夠訪問這個重做日誌文件。如果在Oracle資料庫中,可以根據需要啟動多個歸檔進程ARCH。在Oracle資料庫中,啟動多個歸檔進程時分為手工與自動兩個方式。為了提高重做日誌文件歸檔的速度,當用戶進程發生比較長時間的等待時, LGWR進程會根據時機情況來自動啟動多個歸檔進程。在Oracle資料庫中其最多可以啟動十個歸檔進程。另外如果資料庫管理員在部署資料庫的時候,估計日誌歸檔作業會影響到資料庫的性能,就可以手工來啟動多個歸檔進程。這是通過初始化參數LOG_ARCHIVE_MAX_PROCESSES確定的。可以將這個參數設置為大於1 的數值(注意不能夠超過9個歸檔進程)。如此的話,資料庫在創建常式的時候就會啟動多個歸檔進程。不過筆者還是傾向於讓資料庫系統來自動管理這個進程。資料庫管理員最好不要干涉。

原文地址:
h tt p://database. ctocio.com.c n/4 96/934 9996.shtml

注意去掉空格