① 資料庫應用系統中的核心問題是什麼
資料庫應用系統中的核心問題是資料庫設計。
② 資料庫系統的問題
資料庫管理系統是指MS sql SERVER,ORACLE,DB2這類用於實現對資料庫操作的軟體.
系統軟體平台是指資料庫管理系統所運行的操作系統,比如ORACLE就有運行在WINDOWS上的和LINUX上的不同版本,所以系統軟體平台也很重要.
別的還需要了解不?
③ 資料庫系統的故障有哪些類型恢復系統的主要功能是什麼
可從三個方面去考慮：
1、硬體故障--主機硬體部分的損壞使資料庫無法使用或部分數據丟失。
2、網路故障--線路故障、通信協議等故障使客戶無法訪問資料庫。
3、軟體故障--操作系統、資料庫系統軟體故障使資料庫無法啟動，或者運行不正常。
恢復的主要功能有兩個：恢復丟失的數據和使資料庫正常運行。
④ 資料庫系統故障會造成什麼丟失
資料庫系統中常見的四種故障主要有事務內部的故障、系統故障、介質故障以及計算機病毒故障，對應於每種故障都有不同的解決方法。事務故障表明事務沒有提交或撤銷就結束了，因此資料庫可能處於不準確的狀態。
一、常見的四種故障
(1)事務內部的故障：事務內部故障可分為預期的和非預期的，其中大部分的故障都是非預期的。預期的事務內部故障是指可以通過事務程序本身發現的事務內部故障;非預期的事務內部故障是不能由事務程序處理的，如運算溢出故障、並發事務死鎖故障、違反了某些完整性限制而導致的故障等。
(2)系統故障：系統故障也稱為軟故障，是指資料庫在運行過程中，由於硬體故障、資料庫軟體及操作系統的漏洞、突然停電燈情況，導致系統停止運轉，所有正在運行的事務以非正常方式終止，需要系統重新啟動的一類故障。這類事務不破壞資料庫，但是影響正在運行的所有事務。
(3)介質故障：介質故障也稱為硬故障，主要指資料庫在運行過程中，由於磁頭碰撞、磁碟損壞、強磁干擾、天災人禍等情況，使得資料庫中的數據部分或全部丟失的一類故障。
(4)計算機病毒故障：計算機病毒故障是一種惡意的計算機程序，它可以像病毒一樣繁殖和傳播，在對計算機系統造成破壞的同時也可能對資料庫系統造成破壞(破壞方式以資料庫文件為主)。
二、四種故障的解決方法
(1)預期的事務內部故障：將事務回滾，撤銷對資料庫的修改。
(2)非預期的事務內部故障：強制回滾事務，在保證該事務對其他事務沒有影響的條件下，利用日誌文件撤銷其對資料庫的修改。
(3)系統故障：待計算機重新啟動之後，對於未完成的事務可能寫入資料庫的內容，回滾所有未完成的事務寫的結果;對於已完成的事務可能部分或全部留在緩沖區的結果，需要重做所有已提交的事務(即撤銷所有未提交的事務，重做所有已提交的事務)。
(4)介質故障的軟體容錯：使用資料庫備份及事務日誌文件，通過恢復技術，恢復資料庫到備份結束時的狀態。
(5)介質故障的硬體容錯：採用雙物理存儲設備，使兩個硬碟存儲內容相同，當其中一個硬碟出現故障時，及時使用另一個備份硬碟。
(6)計算機病毒故障：使用防火牆軟體防止病毒侵入，對於已感染病毒的資料庫文件，使用殺毒軟體進行查殺，如果殺毒軟體殺毒失敗，此時只能用資料庫備份文件，以軟體容錯的方式恢復資料庫文件。
⑤ 資料庫系統可能發生的故障種類有哪些
一、事務內部的故障；
二、系統故障；
三、介質故障；
四、計算機病毒。
大致就這四個故障，希望對你有所幫助。
⑥ 請問資料庫系統的一些問題
1X，DBMS實際上是系統軟體，是運行大量應用軟體的基本系統
2X，最小單位是欄位
3X，核心是資料庫
4√，打個勾吧
5√
⑦ 關於資料庫的幾個問題
1.C
2.A
3.A
4.錯誤
5.錯誤
6.正確
7.
外模式
-模式，模式-內模式
8.
數據結構化
，（
數據共享
性高、
冗餘度
低、易擴充）
9.
關系模型
，
面向對象模型
12.數據的安全性保護，數據的完整性保護
15.
實體完整性
，
參照完整性
16.外模式，模式
⑧ 資料庫系統中故障可以分為哪幾類
事務故障
系統故障
介質故障
一、事務故障
什麼是事務故障
某個事務在運行過程中由於種種原因未運行至正常終止點
事務故障的常見原因
輸入數據有誤
運算溢出
違反了某些完整性限制
某些應用程序出錯
並行事務發生死鎖
事務故障（續）
事務故障的恢復
事務故障的恢復：事務撤消（UND）
恢復程序要在不影響其它事務運行的情況下，強行回滾（RBACK）該事務，即清除該事務對資料庫的所有修改，使得這個事務象根本沒有啟動過一樣
二、系統故障
什麼是系統故障
由於某種原因造成整個系統的正常運行突然停止，致使所有正在運行的事務都以非正常方式終止。
發生系統故障時，內存中資料庫緩沖區的信息全部丟失，但存儲在外部存儲設備上的數據未受影響
系統故障（續）
系統故障的常見原因
操作系統或DBMS 代碼錯誤
操作員操作失誤
特定類型的硬體錯誤（如CPU 故障）
突然停電
系統故障（續）
系統故障的恢復
1. 清除尚未完成的事務對資料庫的所有修改
如果DBMS 無法確定哪些事務已更新過資料庫，則系統重新啟動後，恢復程序要強行撤消（UND ） 所有未完成事務，使這些事務象沒有運行過一樣。
2. 將已完成事務提交的結果寫入資料庫
如果DBMS 無法確定哪些事務的提交結果尚未寫入物理資料庫，則系統重新啟動後，恢復程序需要重做（RED ） 所有已提交的事務。
三、介質故障
什麼是介質故障
硬體故障使存儲在外存中的數據部分丟失或全部丟失
介質故障比前兩類故障的可能性小得多，但破壞性最大。
介質故障(續)
介質故障的常見原因
硬體故障
磁碟損壞
磁頭碰撞
操作系統的某種潛在錯誤
瞬時強磁場干擾
介質故障（續）
介質故障的恢復
裝入 資料庫發生介質故障前某個時刻的數據副本
重做自此時始的所有成功事務 ，將這些事務已提交的結果重新記入資料庫
故障的種類小結
資料庫系統中各類故障對資料庫的影響
資料庫本身被破壞 （介質故障）
資料庫處於不一致狀態
資料庫中包含了未完成事務對資料庫的修改（事務故障、系統故障）
資料庫中丟失了已提交事務對資料庫的修改（系統故障）
不同類型的故障應採用不同的恢復操作
故障的種類小結（續）
恢復操作的基本原理：簡單
原理：利用 存儲在系統其它地方的冗餘數據 來重建 資料庫中已經被破壞或已經不正確的那部分數據
恢復的實現技術：復雜
一般一個大型資料庫產品，恢復子系統的代碼要佔全部代碼的10% 以上
⑨ 資料庫系統中的常見故障有哪些
新增archives 時的狀況：
條件和假設：自上次鏡像備份以來已經生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像（冷）拷貝；archive log(s) 可用。
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點： 所有Database Files
所有Control Files（沒有archive(s) 或redo(s) 的情況下，control files 的更新無任何意義）
所有On-Line Redo Logs (Not archives) init.ora file（選項）
3. 啟動資料庫： $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
數據文件, 重作日誌和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的所有所失文件的鏡像（冷）拷貝；archive log(s) 可用
恢復步驟（必須採用不完全恢復的手法）：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點：
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
init.ora file（選項）
3. 啟動資料庫然而並不打開：
svrmgrl>startup mount
4. 做不完全資料庫恢復，應用所有從上次鏡像（冷）備份始積累起來的archives：
svrmgrl> recover database until cancel using backup controlfile;
......
......
cancel
5. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
6. 關閉資料庫並做一次全庫冷備份。
數據文件和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝；archive log(s) 可用
恢復步驟：
1. 將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 選項啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
*** 介質恢復完成
（須在應用完最後一個archive log 後cancel ）
4. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
重作日誌和控制文件同時丟失或損壞時：
條件和假設：Control Files 全部丟失或損壞；Archivelog Mode; 有Control Files 的鏡像（冷）拷貝
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
svrmgrl>exit
2. 以Control File 的鏡像（冷）拷貝覆蓋損壞了的Control File:
$ cp /backup/control1.ctl /disk1/control1.ctl
3. 啟動資料庫然而並不打開：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
4. Drop 壞掉的redo log （排除硬體故障）：
svrmgrl> alter database drop logfile group 2;
5. 重新創建redo log:
svrmgrl> alter database add logfile group 2 '/orig_loc/log2.dbf' size 10M;
6. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
（必須馬上cancel ）
7. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
8. 關閉資料庫並做一次全庫冷備份
只發生歸檔重作日誌丟失或損壞時：
根據不同環境和情況，選擇下述手段之一：
a. 馬上backup 全部datafiles （如果系統採用一般熱備份或RMAN 熱備份）
b. 馬上正常關閉資料庫並進行冷備份（如果系統採用冷備份）
c. 冒險前進！不做備份而讓資料庫接著跑，直等到下一個備份周期再做備份。這是在賭資料庫在下一個備份周期到來之前不會有需要恢復的錯誤發生。
注意:冒險前進的選擇：如果發生錯誤而需要資料庫恢復，則最多隻能恢復到出問題archive log 之前的操作現場。從另一個角度講，archive log(s) 出現問題時，資料庫若不需要恢復則其本身並沒有任何問題。
Oracle邏輯結構故障的處理方法：
邏輯結構的故障一般指由於人為的誤操作而導致重要數據丟失的情況。在這種情況下資料庫物理結構是完整的也是一致的。對於這種情況採取對原來資料庫的全恢復是不合適的，我們一般採用三種方法來恢復用戶數據。
採用exp/imp工具來恢復用戶數據：
如果丟失的數據存在一個以前用exp命令的備份，則可以才用這種方式。
1. 在資料庫內創建一個臨時用戶：
svrmgrl>create user test_user identified by test;
svrmgrl>grant connect，resource to test_user;
2. 從以前exp命令備份的文件中把丟失數據的表按照用戶方式倒入測試用戶：
$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
3. 用相應的DML語句將丟失的數據從測試用戶恢復到原用戶。
4. 將測試用戶刪除：
svrmgrl>drop user test_user cascede;
採用logminer來恢復用戶數據：
Logminer是oracle提供的一個日誌分析工具。它可以根據數據字典對在線聯機日誌、歸檔日誌進行分析，從而可以獲得資料庫的各種DML操作的歷史記錄以及各種DML操作的回退信息。根據這些用戶就可以將由於誤操作而丟失的數據重新加入資料庫內。
1. 確認資料庫的utl_file_dir參數已經設置，如果沒有則需要把這個參數加入oracle的初始化參數文件，然後重新啟動資料庫。下面例子中假設utl_file_dir=』/opt/oracle/db01』；
2. 創建logminer所需要的數據字典信息，假設生成的數據字典文本文件為dict.ora：
svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora'， dictionary_location=>'/opt/oracle/db01』);
3. 確定所需要分析的日誌或者歸檔日誌的范圍。這可以根據用戶誤操作的時間來確定大概的日誌范圍。假設用戶誤操作時可能的日誌文件為/opt/oracle/db02/oradata/ORCL/redo3.log和歸檔日誌』/opt/oracle/arch/orcl/orclarc_1_113.ora』。
4. 創建要分析的日誌文件列表，按日誌文件的先後順序依次加入：
svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>』/opt/oracle/arch/orcl/orclarc_1_113.ora』，options=>dbms_logmnr.NEW);
svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>』 /opt/oracle/db02/oradata/ORCL/redo3.log』，options=>dbms_logmnr.ADDFILE);
5. 開始日誌分析，假設需要分析的時間在』2003-06-28 12:00:00』和』2003-06-28 13:00:00』之間：
svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>』 /opt/oracle/db01/dict.ora』，starttime=>to_date(』 2003-06-28 12:00:00』，』YYYY-MM-DD HH:MI:SS』)，endtime=>to_date(to_date(『2003-06-28 13:00:00』，』YYYY-MM-DD HH:MI:SS』));
6. 獲取分析結果：
svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;
7. 根據分析結果修復數據。
8.結束logmnr:
svrmgrl>dbms_logmnr.end_logmnr;
9. 用適當的方法對原資料庫進行資料庫全備份。
利用備份恢復用戶數據：
採用這種方法時並不是在原資料庫進行恢復，而是利用資料庫備份在新的機器上重新建立一個新的資料庫。通過備份恢復在新機器上將資料庫恢復到用戶誤操作前，這樣就可以獲得丟失的數據將其恢復到原資料庫。
1. 在新的機器上安裝資料庫軟體。
2. 對於採用帶庫備份的現場，需要在新的資料庫伺服器上安裝調試相應的備份管軟體。
3. 根據用戶誤操作的時間點進行基於時間點的資料庫恢復操作。對於沒有採用帶庫備份的現場，可以選取用戶誤操作前最近的備份磁帶進行恢復；對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復。
4.重新打開資料庫：
svrmgrl>alter database open resetlogs;
5. 從新的資料庫中獲取丟失的用戶數據，通過DML操作將其恢復到原資料庫中。
6. 用適當的方法對原資料庫進行資料庫全備份。
⑩ 資料庫運行過程中常見的故障有哪幾類試述對各類故障的恢復策略。
資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。
恢復策略：
1、事物故障：
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。
2、系統故障：
系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。
3、介質故障：
介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。
(10)資料庫的系統問題擴展閱讀：
「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。
資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證資料庫能夠回復到一致的、正確地狀態去。
參考資料來源：網路-事務故障
參考資料來源：網路-系統故障
參考資料來源：網路-介質故障