SQL Server 数据库备份和还原认识和总结(一) ,SQL Server 2012对数据库备份和还原与SQL Server 2008基本没有太大变化,仅对还原时间点选择UI和相关还原选项做了小改动,备份和还原核心没有做变化,这只是个人的掌握和了解,
可能许多同学对SQL Server的备份和还原有一些了解,也可能经常使用备份和还原功能,我相信除DBA之外我们大部分开发员队伍对备份和还原只使用最基础的功能,对它也只有一个大概的认识,如果对它有更深入的认识,了解它更全面的功能岂不是更好,到用时会得心应手。因为经常有中小型客户公司管理人员对数据库不了解或掌握不牢,会请我们技术人员出马找回丢失的数据或硬件损坏移动数据的现象,或其它情况的发生。
首先从数据库【恢复模式】说起,因为数据库如果恢复模式设置不正确,会导致数据无法还原。
SQL Server 2012对数据库备份和还原与SQL Server 2008基本没有太大变化,仅对还原时间点选择UI和相关还原选项做了小改动,备份和还原核心没有做变化,这只是个人的掌握和了解,仅供参考,具体还请以官方文档为依据。以下利用SQL Server 2012 SSMS(SQL Server Management Studio)做图例演示。
SQL Server 2008数据库恢复模式分为三种:完整恢复模式、大容量日志恢复模式、简单恢复模式。
◆ 完整恢复模式。为默认恢复模式。它会完整记录下操作数据库的每一个步骤。使用完整恢复模式可以将整个数据库恢复到一个特定的时间点,这个时间点可以是最近一次可用的备份、一个特定的日期和时间或标记的事务。
◆ 大容量日志恢复模式。它是对完整恢复模式的补充。简单地说就是要对大容量操作进行最小日志记录,节省日志文件的空间(如导入数据、批量更新、SELECT INTO等操作时)。比如一次在数据库中插入数十万条记录时,在完整恢复模式下每一个插入记录的动作都会记录在日志中,使日志文件变得非常大,在大容量日志恢复模式下,只记录必要的操作,不记录所有日志,这样一来,可以大大提高数据库的性能,但是由于日志不完整,一旦出现问题,数据将可能无法恢复。因此,一般只有在需要进行大量数据操作时才将恢复模式改为大容量日志恢复模式,数据处理完毕之后,马上将恢复模式改回完整恢复模式。
◆ 简单恢复模式。在该模式下,数据库会自动把不活动的日志删除,因此简化了备份的还原,但因为没有事务日志备份,所以不能恢复到失败的时间点。通常,此模式只用于对数据库数据安全要求不太高的数据库。并且在该模式下,数据库只能做完整和差异备份。
了解了以上数据库还原模式后,一般就应该知道将自己的数据库设置为何种模式了。备份数据库,SQL Server 2008提供了四种备份方式:完整备份、差异备份、事务日志备份、文件和文件组备份。
◆ 完整备份:备份整个数据库的所有内容,包括事务日志。该备份类型需要比较大的存储空间来存储备份文件,备份时间也比较长,在还原数据时,也只要还原一个备份文件。
◆ 差异备份:差异备份是完整备份的补充,只备份上次完整备份后更改的数据。相对于完整备份分来说,差异备份的数据量比完整数据备份小,备份的速度也比完整备份要快。因此,差异备份通常作为常用的备份方式。在还原数据时,要先还原前一次做的完整备份,然后还原最后一次所做的差异备份,这样才能让数据库里的数据恢复到与最后一次差异备份时的内容相同。
◆ 事务日志备份:事务日志备份只备份事务日志里的内容。事务日志记录了上一次完整备份或事务日志备份后数据库的所有变动过程。事务日志记录的是某一段时间内的数据库变动情况,因此在进行事务日志备份之前,必须要进行完整备份。与差异备份类似,事务日志备份生成的文件较小、占用时间较短,但是在还原数据时,除了先要还原完整备份之外,还要依次还原每个事务日志备份,而不是只还原最后一个事务日志备份(这是与差异备份的区别)。
◆ 文件和文件组备份。如果在创建数据库时,为数据库创建了多个数据库文件或文件组,可以使用该备份方式。使用文件和文件组备份方式可以只备份数据库中的某些文件,该备份方式在数据库文件非常庞大时十分有效,由于每次只备份一个或几个文件或文件组,可以分多次来备份数据库,避免大型数据库备份的时间过长。另外,由于文件和文件组备份只备份其中一个或多个数据文件,当数据库里的某个或某些文件损坏时,可能只还原损坏的文件或文件组备份。
完整备份可能比较好理解。例如,在2012年1月1日早上8点进行了完整备份,那么将来在还原时,就可以恢复到2012年1月有1日早上8点时的数据库状态。
差异备份是备份完整备份后的数据变动情况。例如,在2012年1月1日早上8点进行了完整备份后,在1月2日和1月3日又分别进行了差异备份,那么在1月2日的差异备份里记录的是从1月1日到1月2日这一段时间里的数据变动情况,而在1月3日的差异备份里记录的是从1月1日到1月3日这一段时间里的数据变动情况。因此,如果要还原到1月3日的状态,只要先还原1月1日做的完整备份,再还原1月3日做的差异备份就可以了。
事务日志备份是以事务日志文件作为备份对象,相当于将数据库里的每一个操作都记录下来了。假设在2012年1月1日早上8点进行了完整备份后,到1月2日早上8点为止,数据库里的数据变动了100次,如果此时做了差异备份,那么差异备份记录的是第100次数据变动后的数据库状态,而如果此时做了事务日志备份,备份的将是这100次的数据变动情况。
再举一个例子,例如在2012年1月1日早上8点进行了完整备份后,在1月2日和1月3日又进行了事务日志备份,那么在1月2日的事务日志备份里记录的是从1月1日到1月2日这一段时间里的数据变动情况,而在1月3日的事务日志备份里记录的是从1月2日到1月3日这一段时间里的数据变动情况。因此,如果要还原到1月3日的数据,需要先还原1月1日做的完整备份,再还原1月2日做的事务日志备份,最后还要还原1月3日所做的事务日志备份。
了解了以上数据库备份方式后,便可以针对自己的数据库利用以上方式来备份数据库了。合理备份数据库需要考虑几方面,首先是数据安全,其次是备份文件大小,最后是做备份和还原能承受的时间范围。
例如,如果数据库里每天变动的数据量很小,可以每周(周日)做一次完整备份,以后的每天(下班前)做一次事务日志备份,那么一旦数据库发生问题,可以将数据恢复到前一天(下班时)的状态。
当然,也可以在周日时做一次完整备份,周一到周六每天下班前做一次差异备份,这样一旦数据库发生问题,同样可以将数据恢复到前一天下班时的状态。只是一周的后几天做差异备份时,备份的时间和备份的文件都会跟着增加。但这也有一个好处,在数据损坏时,只要恢复完整备份的数据和前一天差异备份的数据即可,不需要去恢复每一天的事务日志备份,恢复的时间会比较短。
如果数据库里的数据变动得比较频繁,损失一个小时的数据都是十分严重的损失时,用上面的办法备份数据就不可行了,此时可以交替使用三种备份方式来备份数据库。
例如,每天下班时做一次完整备份,在两次完整备份之间每隔八小时做一次差异备份,在两次差异备份之间每隔一小时做一次事务日志备份。如此一来,一旦数据损坏可以将数据恢复到最近一个小时以内的状态,同时又能减少数据库备份数据的时间和备份数据文件的大小。
在前面还提到过当数据库文件过大不易备份时,可以分别备份数据库文件或文件组,将一个数据库分多次备份。在现实操作中,还有一种情况可以使用到数据库文件的备份。例如在一个数据库中,某些表里的数据变动得很少,而某些表里的数据却经常改变,那么可以考虑将这些数据表分别存储在不同的文件或文件组里,然后通过不同的备份频率来备份这些文件和文件组。但使用文件和文件组来进行备份,还原数据时也要分多次才能将整个数据库还原完毕,所以除非数据库文件大到备份困难,否则不要使用该备份方式。
针对以上备份方案,能看出数据还是不完整吗?比如昨天夜间12点做了完整备份,每隔一小时做了一次事务日志备份,最后一次事务日志备份是今天中午12点,现在是今天中午12点10分,发现数据库数据遭到丢失或破坏,可最后一次事务日志备份是今天中午12点,如果我此时将数据库恢复到12点,那么12点后至12点10分前没遭到破坏的操作数据将丢失(比如数据库有三个表,一个表的数据遭到破坏,其它两个表的数据被其它用户变动)。此时就要用到【尾部日志备份】,尾部日志备份原理是从最后一次事务日志备份的时间点开始,将之后的所有操作进行备份,还原时便可以找到12点后操作的正确数据了。
注:进行尾部日志备份时,数据库将强制停止数据库,此时如果不停止数据库,还有用户继续操作,尾部日志备份将失去意义。SQL Server 2012如果你最后一次备份事务日志后,对数据进行过改动,即发生过事务日志(也就是当前日志文件记录的LSN(日志序列号)大于最后一次事务日志备份里记录的最大LSN,SQL Server通过LSN来区分日志的记录),并尚未对尾部日志备份,它会提示并要求你必须先做尾部备份。
实例部分:
◆ 首先进行完整备份【MyTest.bak】,然后再基于此备份文件进行两次事务日志备份,最后一次事务日志备份时间为【2012-8-4 23:07】
图1-1:备份文件名为【MyTest.bak】,最后一次事务日志备份时间为【2012-8-4 23:07】
图1-2:选择备份文件“MyTest.bak”后,此时能看到“要还原的备份集”列表里显示有备份文件,分别列出了完整备份文件和两次事务日志备份。
以上备份文件最后一次事务日志备份时间为【2012-8-4 23:07】,那么,您可以还原到自首次完整备份开始后,至最后一次事务日志备份时间期间的任何一个时间点,这就充分验证上上文讲到的事务日志备份方式(如果后期进行过尾部日志备份,还原时在“要还原的备份集”列表里的最后一行会列出尾部日志记录)。
如果事务日志备份有两次,分别是“事务日志1”、“事务日志2”,那么在还原时去掉“事务日志1”复选框,“事务日志2”也会自动去掉,但只去掉“事务日志2”是允许的,这也充分验证了上文讲到的:“在还原数据时,除了先要还原完整备份之外,还要依次还原每个事务日志备份,而不是只还原最后一个事务日志备份”,不比差异备份可以基于完整备份,只还原最后一次差异备份即可。
图1-3:我【2012-08-04 23:36:53】插入一条数据,【2012-08-04 23:37:44】又做了一次事务日志备份3,然后再将时间点还原到【2012-08-04 23:36:00】,还原后,此时间点后的数据就没有了。
【注意:在还原时会提示数据库正在使用,一般要断开全部连接后,才能进行还原。我一般使用脚本将数据脱机再联机,所有连接将会全部断开】
alter database MyTest set offline with ROLLBACK IMMEDIATE--脱机
alter database MyTest set online with ROLLBACK IMMEDIATE--联机
◆ 如果你最后一次是做的完整备份,基于完整备份想还原到某个时间点是不允许的。
图2-1:备份文件名为【MyTestA.bak】,备份时间为【2012-8-4 22:33】
图2-2:先选择最后一次完整备份文件MyTestA,此时能看到“要还原的备份集”列表里显示有备份文件,然后再点“时间线”按钮进入“备份时间线”界面,将最后一次完整备份时间由“22:33:41”改为它之前任何一个时间点,如改为“22:32:41”,然后再确定,会看到图2-3的效果。
图2-3:只要基于完整备份再还原到某个时间点是不允许的,因为完整备份后没做过任何差异备份或事务日志备份。此时能看到“要还原的备份集”列表里显示为空,无法进行还原。

산성 속성에는 원자력, 일관성, 분리 및 내구성이 포함되며 데이터베이스 설계의 초석입니다. 1. 원자력은 거래가 완전히 성공적이거나 완전히 실패하도록합니다. 2. 일관성은 거래 전후에 데이터베이스가 일관성을 유지하도록합니다. 3. 격리는 거래가 서로를 방해하지 않도록합니다. 4. 지속성은 거래 제출 후 데이터가 영구적으로 저장되도록합니다.

MySQL은 데이터베이스 관리 시스템 (DBMS) 일뿐 만 아니라 프로그래밍 언어와 밀접한 관련이 있습니다. 1) DBMS로서 MySQL은 데이터를 저장, 구성 및 검색하는 데 사용되며 인덱스 최적화는 쿼리 성능을 향상시킬 수 있습니다. 2) SQL과 같은 ORM 도구를 사용하여 Python에 내장 된 SQL과 프로그래밍 언어를 결합하면 작업을 단순화 할 수 있습니다. 3) 성능 최적화에는 인덱싱, 쿼리, 캐싱, 라이브러리 및 테이블 부서 및 거래 관리가 포함됩니다.

MySQL은 SQL 명령을 사용하여 데이터를 관리합니다. 1. 기본 명령에는 선택, 삽입, 업데이트 및 삭제가 포함됩니다. 2. 고급 사용에는 조인, 하위 쿼리 및 집계 함수가 포함됩니다. 3. 일반적인 오류에는 구문, 논리 및 성능 문제가 포함됩니다. 4. 최적화 팁에는 인덱스 사용, 선택*을 피하고 한계 사용이 포함됩니다.

MySQL은 데이터 저장 및 관리에 적합한 효율적인 관계형 데이터베이스 관리 시스템입니다. 장점에는 고성능 쿼리, 유연한 트랜잭션 처리 및 풍부한 데이터 유형이 포함됩니다. 실제 애플리케이션에서 MySQL은 종종 전자 상거래 플랫폼, 소셜 네트워크 및 컨텐츠 관리 시스템에서 사용되지만 성능 최적화, 데이터 보안 및 확장성에주의를 기울여야합니다.

SQL과 MySQL의 관계는 표준 언어와 특정 구현의 관계입니다. 1.SQL은 관계형 데이터베이스를 관리하고 운영하는 데 사용되는 표준 언어로, 데이터 추가, 삭제, 수정 및 쿼리를 허용합니다. 2.MySQL은 SQL을 운영 언어로 사용하고 효율적인 데이터 저장 및 관리를 제공하는 특정 데이터베이스 관리 시스템입니다.

InnoDB는 Redologs 및 Undologs를 사용하여 데이터 일관성과 신뢰성을 보장합니다. 1. Redologs는 사고 복구 및 거래 지속성을 보장하기 위해 데이터 페이지 수정을 기록합니다. 2. 결점은 원래 데이터 값을 기록하고 트랜잭션 롤백 및 MVCC를 지원합니다.

설명 명령에 대한 주요 메트릭에는 유형, 키, 행 및 추가가 포함됩니다. 1) 유형은 쿼리의 액세스 유형을 반영합니다. 값이 높을수록 Const와 같은 효율이 높아집니다. 2) 키는 사용 된 인덱스를 표시하고 NULL은 인덱스가 없음을 나타냅니다. 3) 행은 스캔 한 행의 수를 추정하여 쿼리 성능에 영향을 미칩니다. 4) Extra는 최적화해야한다는 Filesort 프롬프트 사용과 같은 추가 정보를 제공합니다.

Temporary를 사용하면 MySQL 쿼리에 임시 테이블을 생성해야 할 필요성이 있으며, 이는 별개의, 그룹 비 또는 비 인덱스 열을 사용하여 순서대로 발견됩니다. 인덱스 발생을 피하고 쿼리를 다시 작성하고 쿼리 성능을 향상시킬 수 있습니다. 구체적으로, 설명 출력에 사용되는 경우, MySQL은 쿼리를 처리하기 위해 임시 테이블을 만들어야 함을 의미합니다. 이것은 일반적으로 다음과 같은 경우에 발생합니다. 1) 별개 또는 그룹을 사용할 때 중복 제거 또는 그룹화; 2) OrderBy가 비 인덱스 열이 포함되어있을 때 정렬하십시오. 3) 복잡한 하위 쿼리 또는 조인 작업을 사용하십시오. 최적화 방법은 다음과 같습니다. 1) Orderby 및 GroupB


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

맨티스BT
Mantis는 제품 결함 추적을 돕기 위해 설계된 배포하기 쉬운 웹 기반 결함 추적 도구입니다. PHP, MySQL 및 웹 서버가 필요합니다. 데모 및 호스팅 서비스를 확인해 보세요.

Eclipse용 SAP NetWeaver 서버 어댑터
Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.

VSCode Windows 64비트 다운로드
Microsoft에서 출시한 강력한 무료 IDE 편집기

SublimeText3 영어 버전
권장 사항: Win 버전, 코드 프롬프트 지원!

ZendStudio 13.5.1 맥
강력한 PHP 통합 개발 환경
