Oracle 9i Data Guard進行資料庫的災難防護（轉）
Oracle 9i Data Guard進行資料庫的災難防護[@more@]Oracle9i Data Guard 透過使用稱為standby database的資料庫來防止出現資料的災難。它透過將primary database資料庫的重做日誌傳到並應用到standby database資料庫來使standby database資料庫與primary database資料庫同步：
可以將重做日誌直接從primary database資料庫同步寫到standby database資料庫來完成完全沒有資料損失的災難保護。這會給primary database資料庫的效能帶來一定的效能損失。
可以將歸檔的重做日誌從primary database資料庫非同步寫到standby database資料庫來使primary database資料庫在極少損失效能的前提下，最小化地減少資料的丟失。
如果重做日誌資料到達standby database資料庫後快速應用到standby database資料庫，則在primary database資料庫出現問題時可以快速地 failover 到standby database資料庫。然而，如果延緩一定時間後再應用重做日誌資料，可以避免primary database資料庫的錯誤快速地傳播到standby database資料庫。
如附圖所示，當聯機重做日誌在本地歸檔時，它們同時透過 Oracle Net 傳送到了standby database：
資料庫資料保護級別
可以用如下的方式設定standby database資料庫來達到不同的資料庫資料保護級別：
Guaranteed protection：規定在修改主資料庫時，至少有一個備用資料庫有效。假如主（Primary Database）備（Standby Database）之間的連線中斷，Oracle會透過中斷主例項的工作來防止主備資料庫之間的資料的不一致，保證無資料丟失。這種模式對資料庫效能的影響較大。
Instant protection：規定在修改主資料庫時，至少有一個備用資料庫有效。與Guaranteed protection模式不同的是當主備資料庫之間的連線中斷時，允許主備資料庫之間的資料的不一致，並當恢復連線後，解決資料不一致的現象。這種模式對主資料庫的效能有較小的影響。
Rapid protection：主資料庫的修改快速應用在備用資料庫上。會出現資料丟失，但對資料庫效能的影響小。
Delayed protection：主資料庫的修改在延遲一定的時間後應用在備用資料庫上。Rapid protection和Delayed protection模式即使在網路連線有效時，也允許主資料庫與所有的備用資料庫有資料分歧，資料的丟失量等同於主資料庫聯機重做日誌的未歸檔數。這種方式對資料庫效能的影響小。
如何限制資料的丟失量
在primary/standby配置下，所有的歸檔日誌被髮送到了standby 節點，這使standby 節點的資料保持著更新。但是，如果primary 資料庫意外關閉，聯機的日誌將會丟失，因為它們尚未歸檔併傳送到standby節點。這使得 primary 和standby 資料庫之間會有一個差異。
Oracle9i 可以用以下的方法來限制這個差異：
DBA可以選擇讓LGWR在將重做日誌資料寫到本地磁碟的同時將資料傳送到 standby 資料庫。該功能稱為standby零資料丟失（standby zero data loss）。這種方法從本質的角度講提供了遠端重做日誌映象，但帶來的問題是會極大地損失效能。
設定系統初始化引數ARCHIVE_LAG_TARGET.該引數是一個日誌檔案開始使用到被髮送到standby資料庫的時間間隔。該引數的推薦值是 1800秒（需要注意的是，沒有傳送到 standby 資料庫的已經提交的事務會丟失，因此長的事務會使standby資料庫損失更多的資料）。
Oracle9i Data Guard資料防護與Oracle8 Standby Database的關係Oracle Standby Database 是最經常使用的最有效的災難解決方案。在過去版本的基礎上，Oracle9i 又進行了許多改進，使其功能遠遠超過了基本的災難恢復要求。透過將複雜的工作自動化，並對監控、警告、以及控制機制的大規模改進，Standby Database 和一些新的模組可以幫助DBA 從錯誤操作、癱瘓、以及其它的災難中恢復（這些災難都可能毀掉資料庫）。另外，透過使用Oracle9i Standby Database，由於硬體和軟體升級造成的當機時間也可以極度縮短。
Oracle9i 將改進過的8版本的Standby Database功能，與幾個新增加的防止使用者錯誤和癱瘓的模組合起來稱為Oracle9i Data Guard。
Oracle8 Automated Standby Database 提供了建立和自動維護生產資料庫複製的手段來防止災難的發生。Oracle8 Automated Standby Database 具有以下的功能：
當primary database 產生日誌後，系統自動用歸檔日誌更新standby databases.一個primary database可以最多有4個standby databases.這4個standby databases是與primary database完全一樣的複製，它們都可以接管primary database的處理。
Oracle使用標準的恢復方法來將歸檔日誌應用到每個standby databases.這些日誌的應用是自動的，DBA也可以人工應用這些日誌。
primary database 處於開啟和活動狀態，而standby database處於恢復或者開啟只讀狀態。
大多數的基於Oracle8的災難保護方案包括一個Automated Standby Database.因為Oracle資料庫可以用備份和日誌恢復，所以任何應用都可以使用Automated Standby Database.透過Oracle Net傳輸歸檔日誌對primary database的效能影響可以忽略不計。
物理的Standby Database和邏輯的Standby Database
Standby Database可以分為物理的Standby Database和邏輯的Standby Database：
物理 Standby Database。物理 Standby Database是Oracle8 Automated Standby Database的Oracle9i版本。它們之間只有一個差異：日誌傳輸服務現在是一個分離的模組，並支援物理standby database和新的邏輯standby database。
物理Standby Database的含義是Standby Database在物理上與primary database 一樣。因為恢復是使用 ROWID 一塊對一塊進行的，Standby Database的資料塊與primary database的資料快一樣。資料庫模式一定是一樣的，且不能以讀/寫的方式開啟。
邏輯 Standby Database.邏輯 Standby Database是將歸檔的日誌轉化為SQL事務，並將它們應用到開啟的Standby Database.因為資料庫是開啟的，它在物理上與primary database是不一樣的。然而，從邏輯角度講，Standby Database與primary database是一樣的，因此可以接管primary database的處理。在這種情況下，Standby Database還可以併發地進行其它的工作，例如建立一些與primary database不一樣的索引和物化檢視，完成決策支援等任務。
邏輯 Standby Database 是最重要的資料保護特性。就像物理 standby database一樣，它使用歸檔的日誌在standby database上進行處理，在primary database出現問題的情況下也沒有問題。
當選擇使用物理standby database、邏輯standby database、或兩者都用時，要考慮以下一系列的因素。
邏輯standby database可用於兩個目的。當要對邏輯standby database進行改變時，其資料庫可以開啟。
邏輯standby database需要DBA更高的技能。
使資料保護極大化的解決方案通常包括邏輯的和物理的standby databases.資料庫Failover和Switchover當主資料庫發生當機，且不能及時恢復時，Oracle會丟棄主資料庫，將備用資料庫轉變為主資料庫。當 failover之後，備用資料庫變成為主資料庫，從而丟失了備用資料庫的所有能力，也就是說，不能再返回到備用模式。
Failover 有以下特點：
主資料庫offline，備用資料庫online，這種操作由系統和軟體失敗引起。
即使在備用資料庫上應用重做日誌，也可能出現資料丟失的現象，除非備用資料庫執行在guaranteed protection模式下。
原主資料庫重新使用時必須reinstantiated（start instance）。
其它的備用資料庫也需reinstantiated.
在主資料庫正常工作時，Oracle 允許 DBA 將主資料庫切換到備用資料庫，此備用資料庫變為主資料庫，而原主資料庫變為備用資料庫。
資料庫的切換可以從主資料庫角色切換到備用資料庫角色，也可從備用資料庫角色切換到主資料庫角色。
Switchover 有以下特點：
故意將主資料庫offline，而將另一備用資料庫online.可以如使用Switchover 功能完成系統的平滑升級工作。
即使在備用資料庫上不應用重做日誌，也不會造成資料的丟失。
資料庫不需reinstantiated.這使主資料庫幾乎能立即在備用資料庫上恢復它的功能，因此可經常進行定期維護而不需中斷操作。
Oracle9i Data Guard的一些部件日誌傳輸服務（Log Transport Services）
Log Transport Services會被物理的和邏輯的standby database 都用到。它提供的功能包括控制不同的日誌傳輸機制、日誌傳輸錯誤處理和報告、以及在系統失敗後獲取丟失的日誌。使用任何新的日誌傳輸模式，資料的保護都可以得到保證。
Oracle9i Data Guard Broker
Data Guard broker提供了對日誌傳輸服務的監測、控制、和自動化以及邏輯和物理standby的部件。例如，透過只用一個命令就可以啟動 failover，Data Guard broker可被用於控制主要角色從primary到任何一種standby database轉移的整個過程。使用者可以從2種不同的介面來選擇進行角色轉換，使standby database 從primary database接管生產資料庫的處理。一種選擇是使用新的Oracle Enterprise Manager Data Guard Manager。該圖形使用者介面工具可進行大多的配置工作和操作功能。另一種選擇是一個命令列工具，它提供了基本的監測、改變角色需要的所有命令、以及配置和設定Oracle9i Data Guard環境的能力。
Data Guard Manager 是Oracle Enterprise Manager的一部分。
Oracle9i LogMiner
在 Oracle9i中，LogMiner被做了極大的改進。LogMiner是一個關係工具，DBA可以利用這個工具使用SQL進行讀、分析、和解釋日誌檔案。LogMiner可以檢視聯機的和歸檔的重做日誌檔案。
LogMiner技術提供了邏輯standby database用到的基礎結構。新的Oracle Enterprise Manager應用Oracle9i LogMiner Viewer 對已經存在的命令列介面增加了一個圖形操作介面。
災難恢復伺服器（Disaster Recovery Server）和DRMON
在當今的電子商務世界中，在互連網上做生意的公司必須有一套一旦出現問題恢復應用和資料庫的策略。每個DBA都應考慮災難恢復以及計劃好的或意外的failover。Disaster Recovery (DR) Server 是幫助DBA達到更高系統可用性的產品的一部分。
Disaster Recovery (DR) Server 從根本上說是一系列鬆散連線的節點組成。這些節點將物理的和邏輯的standby 方案組合成了一個單獨的易管理的災難恢復解決方案。Disaster Recovery (DR) Server節點在物理分佈上是鬆散的，是透過網路連線到一起的。每個 DR Server 節點可能是一個簡單的例項，或是一個複雜的系統（例如一個 fail safe cluster）。DR Server 將這些節點作為一個單獨的分佈計算系統來管理，從而其可用性會高於單獨的節點。
DR Server 是透過將資料在節點間複製來實現其 failover 系統的。資料庫管理員是這樣來配置伺服器的：資料庫和應用在每個節點都啟用。其中，一個節點設計成primary節點，其資料庫對應用來說是完全可用的，且其資料以日誌的形式複製到其它的節點。其它的節點對primary節點來說是standby節點，它們接收從primary節點發來的日誌並改變（從物理上或邏輯上）其資料庫複製。
DR Server的standby節點是隨時準備好在primary節點出現問題時進行接管的，從而在primary 節點出現災難後資料和應用對使用者來說仍然可用。
DR Server結構給DBA主要提供了兩點重要功能：
它提供了DBA從邏輯上配置一個 failover 資源組來達到高可用性的方法。
它指定了組成DR Server 本身的基礎計算框架。
可以將重做日誌直接從primary database資料庫同步寫到standby database資料庫來完成完全沒有資料損失的災難保護。這會給primary database資料庫的效能帶來一定的效能損失。
可以將歸檔的重做日誌從primary database資料庫非同步寫到standby database資料庫來使primary database資料庫在極少損失效能的前提下，最小化地減少資料的丟失。
如果重做日誌資料到達standby database資料庫後快速應用到standby database資料庫，則在primary database資料庫出現問題時可以快速地 failover 到standby database資料庫。然而，如果延緩一定時間後再應用重做日誌資料，可以避免primary database資料庫的錯誤快速地傳播到standby database資料庫。
如附圖所示，當聯機重做日誌在本地歸檔時，它們同時透過 Oracle Net 傳送到了standby database：
資料庫資料保護級別
可以用如下的方式設定standby database資料庫來達到不同的資料庫資料保護級別：
Guaranteed protection：規定在修改主資料庫時，至少有一個備用資料庫有效。假如主（Primary Database）備（Standby Database）之間的連線中斷，Oracle會透過中斷主例項的工作來防止主備資料庫之間的資料的不一致，保證無資料丟失。這種模式對資料庫效能的影響較大。
Instant protection：規定在修改主資料庫時，至少有一個備用資料庫有效。與Guaranteed protection模式不同的是當主備資料庫之間的連線中斷時，允許主備資料庫之間的資料的不一致，並當恢復連線後，解決資料不一致的現象。這種模式對主資料庫的效能有較小的影響。
Rapid protection：主資料庫的修改快速應用在備用資料庫上。會出現資料丟失，但對資料庫效能的影響小。
Delayed protection：主資料庫的修改在延遲一定的時間後應用在備用資料庫上。Rapid protection和Delayed protection模式即使在網路連線有效時，也允許主資料庫與所有的備用資料庫有資料分歧，資料的丟失量等同於主資料庫聯機重做日誌的未歸檔數。這種方式對資料庫效能的影響小。
如何限制資料的丟失量
在primary/standby配置下，所有的歸檔日誌被髮送到了standby 節點，這使standby 節點的資料保持著更新。但是，如果primary 資料庫意外關閉，聯機的日誌將會丟失，因為它們尚未歸檔併傳送到standby節點。這使得 primary 和standby 資料庫之間會有一個差異。
Oracle9i 可以用以下的方法來限制這個差異：
DBA可以選擇讓LGWR在將重做日誌資料寫到本地磁碟的同時將資料傳送到 standby 資料庫。該功能稱為standby零資料丟失（standby zero data loss）。這種方法從本質的角度講提供了遠端重做日誌映象，但帶來的問題是會極大地損失效能。
設定系統初始化引數ARCHIVE_LAG_TARGET.該引數是一個日誌檔案開始使用到被髮送到standby資料庫的時間間隔。該引數的推薦值是 1800秒（需要注意的是，沒有傳送到 standby 資料庫的已經提交的事務會丟失，因此長的事務會使standby資料庫損失更多的資料）。
Oracle9i Data Guard資料防護與Oracle8 Standby Database的關係Oracle Standby Database 是最經常使用的最有效的災難解決方案。在過去版本的基礎上，Oracle9i 又進行了許多改進，使其功能遠遠超過了基本的災難恢復要求。透過將複雜的工作自動化，並對監控、警告、以及控制機制的大規模改進，Standby Database 和一些新的模組可以幫助DBA 從錯誤操作、癱瘓、以及其它的災難中恢復（這些災難都可能毀掉資料庫）。另外，透過使用Oracle9i Standby Database，由於硬體和軟體升級造成的當機時間也可以極度縮短。
Oracle9i 將改進過的8版本的Standby Database功能，與幾個新增加的防止使用者錯誤和癱瘓的模組合起來稱為Oracle9i Data Guard。
Oracle8 Automated Standby Database 提供了建立和自動維護生產資料庫複製的手段來防止災難的發生。Oracle8 Automated Standby Database 具有以下的功能：
當primary database 產生日誌後，系統自動用歸檔日誌更新standby databases.一個primary database可以最多有4個standby databases.這4個standby databases是與primary database完全一樣的複製，它們都可以接管primary database的處理。
Oracle使用標準的恢復方法來將歸檔日誌應用到每個standby databases.這些日誌的應用是自動的，DBA也可以人工應用這些日誌。
primary database 處於開啟和活動狀態，而standby database處於恢復或者開啟只讀狀態。
大多數的基於Oracle8的災難保護方案包括一個Automated Standby Database.因為Oracle資料庫可以用備份和日誌恢復，所以任何應用都可以使用Automated Standby Database.透過Oracle Net傳輸歸檔日誌對primary database的效能影響可以忽略不計。
物理的Standby Database和邏輯的Standby Database
Standby Database可以分為物理的Standby Database和邏輯的Standby Database：
物理 Standby Database。物理 Standby Database是Oracle8 Automated Standby Database的Oracle9i版本。它們之間只有一個差異：日誌傳輸服務現在是一個分離的模組，並支援物理standby database和新的邏輯standby database。
物理Standby Database的含義是Standby Database在物理上與primary database 一樣。因為恢復是使用 ROWID 一塊對一塊進行的，Standby Database的資料塊與primary database的資料快一樣。資料庫模式一定是一樣的，且不能以讀/寫的方式開啟。
邏輯 Standby Database.邏輯 Standby Database是將歸檔的日誌轉化為SQL事務，並將它們應用到開啟的Standby Database.因為資料庫是開啟的，它在物理上與primary database是不一樣的。然而，從邏輯角度講，Standby Database與primary database是一樣的，因此可以接管primary database的處理。在這種情況下，Standby Database還可以併發地進行其它的工作，例如建立一些與primary database不一樣的索引和物化檢視，完成決策支援等任務。
邏輯 Standby Database 是最重要的資料保護特性。就像物理 standby database一樣，它使用歸檔的日誌在standby database上進行處理，在primary database出現問題的情況下也沒有問題。
當選擇使用物理standby database、邏輯standby database、或兩者都用時，要考慮以下一系列的因素。
邏輯standby database可用於兩個目的。當要對邏輯standby database進行改變時，其資料庫可以開啟。
邏輯standby database需要DBA更高的技能。
使資料保護極大化的解決方案通常包括邏輯的和物理的standby databases.資料庫Failover和Switchover當主資料庫發生當機，且不能及時恢復時，Oracle會丟棄主資料庫，將備用資料庫轉變為主資料庫。當 failover之後，備用資料庫變成為主資料庫，從而丟失了備用資料庫的所有能力，也就是說，不能再返回到備用模式。
Failover 有以下特點：
主資料庫offline，備用資料庫online，這種操作由系統和軟體失敗引起。
即使在備用資料庫上應用重做日誌，也可能出現資料丟失的現象，除非備用資料庫執行在guaranteed protection模式下。
原主資料庫重新使用時必須reinstantiated（start instance）。
其它的備用資料庫也需reinstantiated.
在主資料庫正常工作時，Oracle 允許 DBA 將主資料庫切換到備用資料庫，此備用資料庫變為主資料庫，而原主資料庫變為備用資料庫。
資料庫的切換可以從主資料庫角色切換到備用資料庫角色，也可從備用資料庫角色切換到主資料庫角色。
Switchover 有以下特點：
故意將主資料庫offline，而將另一備用資料庫online.可以如使用Switchover 功能完成系統的平滑升級工作。
即使在備用資料庫上不應用重做日誌，也不會造成資料的丟失。
資料庫不需reinstantiated.這使主資料庫幾乎能立即在備用資料庫上恢復它的功能，因此可經常進行定期維護而不需中斷操作。
Oracle9i Data Guard的一些部件日誌傳輸服務（Log Transport Services）
Log Transport Services會被物理的和邏輯的standby database 都用到。它提供的功能包括控制不同的日誌傳輸機制、日誌傳輸錯誤處理和報告、以及在系統失敗後獲取丟失的日誌。使用任何新的日誌傳輸模式，資料的保護都可以得到保證。
Oracle9i Data Guard Broker
Data Guard broker提供了對日誌傳輸服務的監測、控制、和自動化以及邏輯和物理standby的部件。例如，透過只用一個命令就可以啟動 failover，Data Guard broker可被用於控制主要角色從primary到任何一種standby database轉移的整個過程。使用者可以從2種不同的介面來選擇進行角色轉換，使standby database 從primary database接管生產資料庫的處理。一種選擇是使用新的Oracle Enterprise Manager Data Guard Manager。該圖形使用者介面工具可進行大多的配置工作和操作功能。另一種選擇是一個命令列工具，它提供了基本的監測、改變角色需要的所有命令、以及配置和設定Oracle9i Data Guard環境的能力。
Data Guard Manager 是Oracle Enterprise Manager的一部分。
Oracle9i LogMiner
在 Oracle9i中，LogMiner被做了極大的改進。LogMiner是一個關係工具，DBA可以利用這個工具使用SQL進行讀、分析、和解釋日誌檔案。LogMiner可以檢視聯機的和歸檔的重做日誌檔案。
LogMiner技術提供了邏輯standby database用到的基礎結構。新的Oracle Enterprise Manager應用Oracle9i LogMiner Viewer 對已經存在的命令列介面增加了一個圖形操作介面。
災難恢復伺服器（Disaster Recovery Server）和DRMON
在當今的電子商務世界中，在互連網上做生意的公司必須有一套一旦出現問題恢復應用和資料庫的策略。每個DBA都應考慮災難恢復以及計劃好的或意外的failover。Disaster Recovery (DR) Server 是幫助DBA達到更高系統可用性的產品的一部分。
Disaster Recovery (DR) Server 從根本上說是一系列鬆散連線的節點組成。這些節點將物理的和邏輯的standby 方案組合成了一個單獨的易管理的災難恢復解決方案。Disaster Recovery (DR) Server節點在物理分佈上是鬆散的，是透過網路連線到一起的。每個 DR Server 節點可能是一個簡單的例項，或是一個複雜的系統（例如一個 fail safe cluster）。DR Server 將這些節點作為一個單獨的分佈計算系統來管理，從而其可用性會高於單獨的節點。
DR Server 是透過將資料在節點間複製來實現其 failover 系統的。資料庫管理員是這樣來配置伺服器的：資料庫和應用在每個節點都啟用。其中，一個節點設計成primary節點，其資料庫對應用來說是完全可用的，且其資料以日誌的形式複製到其它的節點。其它的節點對primary節點來說是standby節點，它們接收從primary節點發來的日誌並改變（從物理上或邏輯上）其資料庫複製。
DR Server的standby節點是隨時準備好在primary節點出現問題時進行接管的，從而在primary 節點出現災難後資料和應用對使用者來說仍然可用。
DR Server結構給DBA主要提供了兩點重要功能：
它提供了DBA從邏輯上配置一個 failover 資源組來達到高可用性的方法。
它指定了組成DR Server 本身的基礎計算框架。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9417382/viewspace-937407/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle 9i Data Guard進行資料庫的災難防護簡介(轉)Oracle資料庫
- 9i 克隆+data guard 實現資料庫搬遷資料庫
- 使用Data Guard Broker進行Data Guard物理備用庫配置(Oracle 19c)Oracle
- Oralce 資料庫的災難恢復(轉)資料庫
- Oracle data guard常用維護操作命令(轉)Oracle
- Data Guard 的3種資料保護模式模式
- oracle9204(9i)_dg(data guard)_重新命名主庫資料檔案_指南_轉摘官檔Oracle
- Data Guard之Snapshot Standby資料庫功能[轉]資料庫
- oracle 11g data guard維護Oracle
- 容災技術Data Guard搭建
- Data Guard broker系列之五：資料庫角色轉換資料庫
- oracle10g data guard建立物理standby資料庫的例子Oracle資料庫
- 【轉】【DataGuard】Oracle 11g物理Data Guard之Snapshot Standby資料庫功能Oracle資料庫
- 6 Oracle Data Guard Protection Modes 保護模式Oracle模式
- Oracle RAC & Data Guard搭建高可用資料庫系統方案Oracle資料庫
- 利用Oracle Data Guard完成跨平臺的資料庫遷移案例Oracle資料庫
- Oracle 10g Data Guard的建立與維護Oracle 10g
- 15 Oracle Data Guard Scenarios 保護場景OracleiOS
- oracle data guard!!Oracle
- Data Guard新特性：快照備用資料庫資料庫
- Data Guard Broker系列之四：資料庫管理資料庫
- Oracle9iR2 Data Guard的保護模式(ZT)Oracle模式
- 利用RMAN建立10GRAC資料庫的DATA GUARD資料庫
- 【資料庫資料恢復】ORACLE常見資料災難&資料恢復可能性資料庫資料恢復Oracle
- Oracle資料庫中索引的維護(轉)Oracle資料庫索引
- 細數基於ORACLE 資料庫環境的常見資料災難解決方式Oracle資料庫
- 【DataGuard】使用Grid Control調整Oracle物理Data Guard資料保護模式Oracle模式
- 邏輯Data Guard主備庫的轉換
- 介紹ORACLE DATA GUARD——DATA GUARD概念和管理Oracle
- 管理物理STANDBY資料庫——DATA GUARD概念和管理資料庫
- 建立物理STANDBY資料庫——DATA GUARD概念和管理資料庫
- Oracle Data Guard配置Oracle
- 【DataGuard】Oracle 11g物理Data Guard之Snapshot Standby資料庫功能Oracle資料庫
- oracle10g data guard 主備資料庫配置引數說明Oracle資料庫
- 【DataGuard】調整Data Guard資料保護模式詳細步驟模式
- oracle資料庫災難挽救應急方案之DML誤操作恢復Oracle資料庫
- Oracle資料庫中索引的維護 (轉帖)Oracle資料庫索引
- 使用Spring Data JPA進行資料庫操作Spring資料庫