❶ oracle怎樣完全備份
可以熱備宴斗份：x0dx0asql> alter database begin backupx0dx0a然後退出SQL，將Oracle軟體和數據文件直接拷貝x0dx0a等都拷貝完了，再進sqlplus 執行：x0dx0aSQL>alter database end backupx0dx0a然後將begin時刻到end時刻產生的歸檔也拷貝出來，x0dx0a這就完成了全備x0dx0ax0dx0a如果你要在oracle下備份整個資料庫：可以用expdp方便的進行x0dx0aexpdp sys/XXX mpfile=XXXX.dmp directory=XXXXx0dx0a其中directory是在oracle下建立的文件夾對象名x0dx0a假如你晌孫磨沒建立過x0dx0a那麼首先執行create directory dpdata1 as 'd:\test\mp'x0dx0a然後把expdp這樣凱隱寫directory=dpdata1
❷ MySQL的備份與還原，非常規備份，全量備份，增量備份
1：官方百萬級別的測試資料庫：
官方測試資料庫github網址：https://github.com/datacharmer/test_db
下載到目錄，解壓即可，運行命令：
2：自己創建簡單測試資料庫：
快速隨機生成測試語言的網站：https://generatedata.com/
選擇sql和想生成的欄位，點擊生成Generate!生成即可。
在MySQL輸入生成的語句即可。
3：測試備份還原時用到的命令
刪庫跑路測試（先備份好）
還原後查詢庫的表數據是否完整。
採用復制整個數據存放目錄
1：查看資料庫數據存放位置
有兩種方法：
1)：在資料庫中用命令 show variables like 'datadir' 查看
2)：在配置文件中查看，配置了 datadir 目錄的可查看。沒有配置的默認為 /var/lib/mysql/ 位置
Linux中查看配置文件
2：復制目錄或者目錄下某個資料庫名
3：還原時直接復制文件夾到資料庫目錄即可
mysqlmp又可叫做全量備份。
參數 --databases 同 -B ，單獨一個庫，也可省略。
1、備份命令mysqlmp格式
格式：mysqlmp -h主機名 -P埠 -u用戶名 -p密碼 database 資料庫名 > 文件名.sql
備份testDatabase資料庫
2、備份MySQL資料庫為帶刪除表的格式
備份MySQL資料庫為帶刪除表的格式，能夠讓該備份覆蓋已有資料庫而不需要手動刪除原有資料庫。
3、直接將MySQL資料庫壓縮備份
備份並壓縮
4、備份MySQL資料庫某個(些)表
備份testDatabase中的myTable表，不需要用參數 --databases 或者 -B
5、同時備份多個MySQL資料庫
同時備份testDatabase和 employees兩個庫
6、備份伺服器上所有資料庫
參數 --all-databases 同 -A
7、還原MySQL資料庫的命令
1) 不指定數據名還原，默認生成原資料庫名稱，還原所有資料庫。
2) 指定數據名還原，還原指定單個資料庫，需在資料庫種預先創建一個testDatabase名稱。
3) 還原壓縮的MySQL資料庫
4) 進入資料庫用source導入
增量備份是針對於資料庫的bin-log日誌進行備份的，增量備份是在全量的基礎上進行操作的。增量備份主要是靠mysql記錄的bin-log日誌。
1：查看是否開啟bin-log日誌
進入mysql輸入命令可查看。
顯示如下為開啟狀態，日誌文件在/var/lib/mysql/以binlog.00001的格式保存。
如未開啟，需要在配置文件種配置
2：查看目前使用的bin-log日誌文件
進入mysql查看命令。
顯示如下，目前使用的是binlog.000022文件，所有操作都記錄在此文件。
查看當前testDatabase的表myTable數據如下，
3：刷新日誌，使用新的日誌文件（備份）
在命令端執行命令
日誌文件從 binlog.000022 變為 binlog.000023
這時相當與已經備份成功，備份文件即為上次的binlog.000022日誌文件。
4：刪除數量，從日誌還原數據
1) 刪除ABC行
查詢以及沒有ABC行列。
2) 恢復數據ABC行
退出mysql，在命令端用mysqlbinlog命令恢復到binlog.000022日誌狀態。
進入資料庫再次查看數據，ABC已經恢復。
增量備份完成。
❸ 如何備份整個mysql資料庫
1、首先打開mysql資料庫軟體進入軟體主界面。
❹ 資料庫SQL 如何完全備份
第1步，依次單擊「開始」→「所有程序」→Microsoft
SQL
Server→「企業管理器」，打開「企業管理器」控制台窗口。
第2步，在企業管理器控制台窗口的左窗格中依次展開「Microsoft
SQL
Servers/SQL
Server組/local」目錄樹。然後用滑鼠右鍵單擊「資料庫」選項，在彈出的快捷菜單中執行「所有任務」→「備份資料庫」命令。
第3步，打開「SQL
Server
備份」對話框，然後單擊「資料庫」右側的下拉三角，從中選擇要備份的資料庫名稱（本例採用默認的Master資料庫）。在「名稱」編輯框中可以鍵入備份生成的文件名稱。接著單擊「添加」按鈕。
第4步，在打開的「選擇備份目的」對話框中，單擊「文件名」編輯框右側瀏覽按鈕，打開「備份設備位置」對話框。在該對話框中找到本地硬碟中用於保存備份資料庫文件的文件夾（本例為L:\SQLBackup文件夾），然後在「文件名」編輯框中為備份文件鍵入一個合適的名稱。設置完成以後單擊「確定」按鈕。
第5步，回到「選擇備份目的」對話框，可以在「文件名」編輯框中看到剛才所作的設置，單擊「確定」按鈕即可。
第6步，SQL
Server開始按照指定的備份目的對資料庫進行備份，備份完成後會給出提示，單擊「確定」按鈕即可，
❺ 請問簡述數據備份的三種方法
數據備份的三種方法如下：
1、完全備份。完全備份是指拷貝整個磁碟卷或邏輯磁碟的內容。
2、增量備份。增量備份即備份自從上次備份孫彎尺操作以來新改變的數據，這些新改變的數據或者是新產生的數據，或者是更新的數據。
3、差量備份。差量備份即拷貝所有新的數據，這些數據都是上一次完全備份後產生或者更新的，差量備份與增量備份類似，但也有不同。
備份是一種將文件系統或資料庫系統中的數據加以復制，一旦發生災難則高或錯誤操作時，得以方便而及時地恢復系統的有效數據和正常運作的方法。備份存儲媒體既可以是邏輯驅動器（如硬碟）、獨立的存儲設備（如可移動磁碟），也可以是由自動轉換器組織和控制的整個磁碟庫或磁帶庫。最好將重要數據製作三個或三個以上的備份，並且放置在不同的場所，以利日後回存之用。
更多鬧配關於簡述數據備份的三種方法，進入：https://m.abcgonglue.com/ask/fa57b21615833038.html?zd查看更多內容
❻ MySQL 常用備份工具流程解析
下面我們就看一下常見的備份工具，以及目前最流行的 Percona XtraBackup 的備份流程。
MySQL 常見的備份工具主要分為三種：
這里先說一下 binlog 備份，它只是把 binlog 又復制了一份，並且需要在邏輯備份或者物理備份的基礎上才能進行數據恢復，無法單獨進行數據恢復。
mysqlmp 備份出的文件就是 sql 文件，其核心就是對每個表執行 select ，然後轉化成相應的 insert 語句。mysqlmp 的備份流程大致如下：
從上面可以看出在 mysqlmp 備份期間，備份到某個資料庫時，該資料庫下的表都會處於只讀狀態，無法對表進行任何變更，直到該庫下的表備份完畢，這對於線上環境一般是無法接受的。若是指定了--master-data或者 --mp-slave 則會在備份開始時加全局讀鎖（FLUSH TABLES WITH READ LOCK），直到備份結束。當然我們可以選一個從庫進行備份，這樣就不會影響線上業務。另外使用 mysqlmp 備份還有一個最大的好處，因為備份出來的是 sql 語句，所以它支持跨平台和跨版本的數據遷移或者恢復，這是物理備份無法做到的。
但是也正是因為 mysqlmp 備份出來的是 sql 語句，在使用時要更加註意，否則可能會釀成大禍。例如，使用 mysqlmp 常見的問題有：
所以使用 mysqlmp 時一定要了解各個選項的作用，以及確認備份出來的 sql 文件里會有什麼操作，會對現有數據造成什麼影響。
Mymper 原理與 Mysqlmp 原理類似，最大的區別是引入了多線程備份，每個備份線程備份一部分表，當然並發粒度可以到行級，達到多線程備份的目的。這里不再單獨介紹。
Percona XtraBackup 是 Percona 公司開發的一個用於 MySQL 資料庫物理熱備的備份工具，是基於 InnoDB 的崩潰恢復功能來實現的。它的基本工作原理如下：
Percona XtraBackup 在進行恢復時會應用拷貝的 redo log ，應用已提交的事務，回滾未提交的事物，將資料庫恢復到一致性狀態。因為 Percona XtraBackup 備份出來的是物理文件，所以在使用備份出的文件進行恢復或者遷移時，不會像 mysqlmp 那樣會存在很多問題。
使用 XtraBackup 備份時根據備份參數設置不同，對資料庫的變更會造成不同程度的影響，具體影響會在下文分析。
通過對比發現，XtraBackup 具有對資料庫影響小，且能快速恢復的優點，在日常備份中是首選；mysqlmp 使用相對更加靈活，但是使用是要注意對資料庫原有數據的影響。
備份策略主要有：全量備份和增量備份，再加上 binlog 備份。
目前去哪兒網資料庫備份主要採用 XtraBackup 全量備份 +binlog 備份。資料庫的重要級別不同，全量備份的頻率不同。備份程序主要架構如下：
說明：
Percona XtraBackup 是目前備份 MySQL 使用最廣泛的工具。在備份過程中，資料庫可以進行正常的讀寫或者其他變更操作，但是偶爾也會遇見備份引起的元數據鎖，或提交事務時發現被 binlog lock 阻塞等情況。下面我們就看一下 Percona XtraBackup 的備份流程和加鎖時機。
說明：以下對 Percona XtraBackup 的分析都是基於 2.4.23 的版本，其他版本會略有差別，但是關鍵步驟基本相同。
XtraBackup 在備份開始時，會創建一個後台線程，專門用於拷貝資料庫的 redo log 。首先 XtraBackup 會掃描每組 redo log 的頭部，找出當前的 checkpoint lsn ，然後從該 lsn 後順序拷貝所有的 redo log ，包括後續新產生的 redo log 。該線程會一直持續到將非事務表完全拷貝完成，才會安全退出。備份日誌輸出中會記錄拷貝開始時的 checkpoint lsn 。日誌輸出如下：
在拷貝ibd文件之前，會先掃描資料庫的數據文件目錄，獲取ibdata1，undo tablespaces及所有的ibd文件列表，並會記錄相應的 space id，因為在恢復時需要這些 space id來找到對應 doublewrite buffer里頁面的內容，以及對應的redo log條目。然後開始循環拷貝ibdata1，undo tablespaces及所有的ibd文件。
這里可通過設置--parallel進行多線程備份，提高物理文件的拷貝效率。不設置則默認為1。
在所有ibd文件拷貝完成後，XtraBackup開始備份非ibd文件。這一部分的邏輯比較復雜，因為備份非ibd文件前需要加鎖，具體是否會加鎖主要受到--no-lock 參數設置的影響。
若是設置了--no-lock為TRUE，則不會使用"FLUSH TABLES WITH READ LOCK"去加全局讀鎖，但是若備份過程中對non-InnoDB表執行了DDL或者DML操作， 這會導致備份的不一致，恢復出來的數據就會有問題。所以是不建議將--no-lock為TRUE，默認值是FALSE，也就是在不指定該選項的情況下會在備份非ibd文件前加全局讀鎖。
下面我們結合源碼來看看判斷是否加全局鎖這部分的具體流程邏輯：
流程圖如下：
總結來看：
1）若--no-lock為FALSE（默認值），則先施加全局讀鎖，然後再進行拷貝文件，另外若 --safe-slave-backup 設置為TRUE ，則會在加全局鎖之前關閉SQL_THREAD線程；
2）若--no-lock為TRUE，則不會施加鎖，直接進行拷貝文件。
加鎖的邏輯主要由lock_tables_maybe實現,先看一下lock_tables_maybe源代碼，如下：
lock_tables_maybe 函數簡化處理流程如下：
1）若備份實例上已經加鎖（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者設置lock-ddl-per-table 則直接返回；
2）若支持備份鎖，則執行LOCK TABLES FOR BACKUP；
3）若不支持備份鎖，則執行 FLUSH TABLES WITH READ LOCK。根據相應選項設置，在執行該操作前會判斷是否有執行中的DDL/DML，以及等待超時時間，是否kill 對應的未結束的事務等。
從上文中我們還看到一個參數--safe-slave-backup ，該參數的主要作用是：
若是在從庫執行的備份操作時設置了該參數，可以防止因從庫同步主庫操作，而導致XtraBackup長時間請求不到鎖而造成備份失敗。
若是設置了 --safe-slave-backup 為TRUE，那麼會執行"STOP SLAVE SQL_THREAD"，並等待Slave_open_temp_tables 為零才開始拷貝非 ibd 文件，Slave_open_temp_tables 為零說明SQL thread執行的事務都已經完成，這樣就能保證備份的一致性。並且此時也不會有在執行的事務阻塞 XtraBackup 施加全局鎖。
備份完非 ibd 文件後，將會備份 slave 和 binlog 信息。
mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1
需要注意，在支持備份鎖的實例上備份，指定了 --slave-info 或--binlog-info 均會先施加 binlog 備份鎖（ LOCK BINLOG FOR BACKUP），這會阻塞任何會更改 binlog 位點的操作。
備份完資料庫的所有文件和binlog等相關信息，備份工作就基本完成了，之後主要執行的操作如下：
1）執行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",將所有的redo log刷盤；
2）停止redo log復制線程；
3）釋放全局讀鎖（備份鎖），binlog鎖；
4）開啟SQL_THREAD；
5）拷貝ib_buffer_pool和ib_lru_mp文件；
6）生成配置文件backup-my.cnf；
7）列印備份信息到xtrabackup_info文件，這些信息主要包含備份時使用的參數信息，備份起止時間，binlog位點信息，以及將會回到的lsn點。
下面是xtrabackup_info記錄的部分內容：
加鎖對應的函數是 mdl_lock_tables ，釋放鎖對應的函數是 mdl_unlock_all，主要是執行COMMIT，結束 mdl_lock_tables 中開啟的顯式事務，來釋放MDL鎖。mdl_lock_tables 流程如下：
上面參數--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之後添加的，因為 MySQL 5.7 新增了一個叫做 Sorted Index Builds 的功能，這會導致某些 DDL 操作不記錄重做日誌而導致備份失敗。使用--lock-ddl或--lock-ddl-per-table 就會在備份開始時施加鎖，阻止 DDL 操作。
另外，若備份時指定了--lock-ddl或--lock-ddl-per-table，則在備份非 ibd 文件時就不是再有加鎖操作。
注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 語句只有在支持備份鎖的實例上才會執行，Percona Server for MySQL已經在 5.6.16-64.0 版本開始支持這種更加輕量的備份鎖。
Q1: 使用 XtraBackup 備份的文件進行恢復時，恢復到哪個時間點？ A1：恢復到執行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的時間點，因為這時任何改變 binlog 位點的操作都會被阻塞，redo log和binlog 是一致的。
Q2: 在開啟 binlog 的情況下，MySQL 的奔潰恢復是同時依賴 binlog 和 redo log 這兩種日誌的，為什麼XtraBackup 不用備份binlog？
A2：因為在備份中有執行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改變binlog位點的操作，這樣只需要根據redo log將有commit log 的事務提交，沒有commit log的事務進行回滾即可。
Q3: 使用Percona XtraBackup備份完成後redo的位點是和binlog是一樣還是比binlog多一些？
A3：通過分析備份流程可以發現備份 binlog 位點信息（加binlog鎖）是發生在停止 redo 拷貝線程前，而釋放鎖是在停止 redo 拷貝線之後，所以 redo log 會多一些。鎖住了 binlog 保證了在該 binlog 位點前已經提交的事務的 redo log 都有 commit log 的信息，未提交的事物也就沒有對應的 commit log 的信息，即便在鎖住 binlog 後有 Innodb 表新的 DML 產生的 redo log ，但是事務無法提交，也就沒有 commit log 的信息的，最後在回放的過程中對沒有 commit log 的事務進行回滾就可以了。
Q4：Percona XtraBackup什麼時候會加鎖，以及影響加鎖時間長度的因素有哪些？
A4：上面進行了分析，加鎖操作只在備份非 ibd 文件時執行，加鎖時長主要和非事務表的數量和大小有關，非事務表的數量越多，體積越大，拷貝文件所用的時間越長，那麼加鎖時間也就越長。也會和 redo log 生成的速度有關，只是 redo log 刷盤受到多個因素的影響，未及時刷盤的 redo log 一般很小。
Q5：Percona XtraBackup 和mysqlmp選擇哪個更好？
A5：通過上面的的解析，若是整個實例備份，首先選擇 Percona XtraBackup ，因為對資料庫的影響最小。若只是備份某個庫表，這個就要視數據量而定，若數據量不大可以使用 mysqlmp 。注意，對資料庫做備份時最好選擇業務連接最少的從庫，因為備份也會消耗一定的資源，避免影響業務。
❼ 資料庫，增量同步和全量同步是什麼
增量同步和全量同步是資料庫同步的兩種方式。全量同步是一次性同步全部數據，增量同步則只同步兩個資料庫不同的部分。
❽ ORACLE全備份和0級增量備份的區別
ORACLE全備份和0級增量備份的區別：
1、Level 0級就是對資料庫一個全庫備份，增量備份必須從0級開始，也就是說必須要有一個全庫備份當基礎。
2、如果做全庫備份oracle也不認為這是level 0的全庫備份，盡管是一樣的也要單獨做一次level 0。
3、有了level 0當基礎才能有後面的 level 1 level 2 level 3 level 4。
全量備份:
1.導出epmssit資料庫備份；
exp system/sysadmin@hnepms file=d:\datas\epmssit_bak20100401.dmp owner=epmssit
2.創建epmsprd用戶以及表空間；
sqlplus "/as sysdba"
create tablespace epmsprd datafile 'D:\datas\epmsprd.ora' size 100M;
create user epmsprd identified by epmsprd default tablespace epmsprd;
grant resource,connect to epmsprd;
3.將epmssit導入到epmsprd用戶；
imp system/sysadmin@hnepms file=d:\datas\epmssit_bak20100401.dmp fromuser=epmssit touser=epmsprd
4.清理epmsprd資料庫中的垃圾數據；
delete from xxxxxx;
5.備份epmsprd；
exp system/sysadmin@hnepms file=d:\datas\epmsprd_bak20100401.dmp owner=epmsprd
❾ 資料庫備份主要包括哪三種方式
全量備份是指對某一時間點上的所有數據進行全量備份，包括系統和所有數據。這種備份方式每次都需要對系統和所有數據進行一次全量備份。這種備份方式最大的好處就是在恢復丟失數據時，只需要對一個完整的備份進行操作就能夠恢復丟失數據，大大加快了系統或數據恢復的時間。
增量備份即在第一次全量備份的基礎上，分別記錄每次的變化。由於增量備份在備份前會判斷數據是否發生變化，並僅記錄每次變化情況，所以相較於其他兩種備份方悄雹肆式它最大的好處在於其所需存儲空間最少的（相同的變化情況下），備份速度最快的。當然在數據還原上來說，它的恢復時間是最長的，效率較低。恢復數據時，需要在第一次完備的基礎上，整合每次的一肆逗個變化情況。
差異備份就是在第一次全量備份的基礎上，記錄最新數據較第一次全量備份的差異。簡單來說，差異備份就是一個積累變化的過程。因此啟轎，恢復系統或者數據時，只需要先恢復全量備份，然後恢復最後一次的差異備份即可完成。所以差異備份佔用的儲存空間和所需恢復時間介於全量備份和增量備份之間。