在Oracle数据库中,主要有两种日志操作模式,分别为非归档模式与归档模式。默认情况下,数据库采用的是非归档模式。作为一个合格的数据库管理员,应当深入了解这两种日志操作模式的特点,并且在数据库建立时,选择合适的操作模式
笔者今天就谈谈自己对这两种操作模式的理解,并且给出一些可行的建议,跟大家一起来提高Oracle数据库的安全性。一、非归档模式的利与弊。
非归档模式是指不保留重做历史的日志操作模式,只能够用于保护例程失败,而不能够保护介质损坏。如果数据库采用的是日志操作模式的话,则进行日志切换时,新的日志会直接覆盖原有日志文件的内容,不会保留原有日志文件中的数据。
这么说听起来可能比较难理解。笔者举一个简单的例子,就会清楚许多。如现在Oracle数据库中有四个日志组,日志序列号分别为11、 12、13、14。当数据库事务变化写满第一个日志组文件(序列号为11)时,Oracle数据库就会自动切换到第二个日志组文件(序列号为12)中。依次类推。当第三个日志组文件(序列号为13)写满时,就会切换到第四个日志组(序列号为14)。当第四个日志组(序列号为14)满时,其就会切换到第一个日志组(序列号为15)。这里,序列号虽然与刚才第一个日志文件组不同,但是日志组仍然是同一个。此时,由于数据库的操作模式选择为非归档模式,所以第一组日志文件(序列号为11)中的内容并没有归档。新的日志文件的内容将直接覆盖第一个日志组文件中的内容。若第一个日志组文件(序列号为15)满时,切换到第二个日志文件组时,新的内容又会在第二个日志文件组没有归档的情况下,直接覆盖日志文件12中的原有数据。
通过以上的分析,我们可以归纳出非归档操作日志模式的一些特点。
一是当检查点完成之后,后台进程可以覆盖原有重做日志的内容。也就是说,在日志切换时,后来的日志文件内容可以在以前的日志文件内容没有归档的情况下,覆盖原有日志文件的内容。如此的话,当出现数据文件损坏时,数据库管理员只能够恢复到过去的完全被分点。如数据库有四个日志组。如果在日志组序列号为16的时候数据库管理员进行了完全备份。而在日志组序列号为28的时候数据文件出现了损坏。此时,由于中间的日志文件内容被覆盖掉了。所以,此时数据库管理员只能够恢复到完全备份的那个点,而不能够恢复数据库文件损坏时的点的数据(即序列号为28)的数据。如果在序列号为18的时候出现了数据文件损坏的事故,则可以先对数据库进行还原(还原点为序列号为16时的数据),然后再利用重做日志文件(序列号为17、18),即可以把数据恢复到故障发生时的数据。故虽然不用对重做日志文件进行归档,节省磁盘空间。但是,却给后续数据库的恢复带来的麻烦,降低了数据库的安全性。为此,如何取舍,还是需要数据库管理员根据自己企业的情况,作出选择。
二是执行数据库备份时,必须要备份所有数据文件和控制文件。根据上面笔者所讲述的,因为重做日志会被后来的所覆盖,所以,基本上数据库管理员不能够通过重做日志文件来恢复数据库的数据,或者说,通过重做日志文件不能够恢复全部的数据。为此,在执行数据库备份时,就必须备份所有的数据文件和控制文件。同时,还必须使用SHUTDOWNNORMAL等命令关闭数据库。
二、归档日志模式。
归档日志模式与非归档日志模式相对应,是指保留重做日志历史的日志操作模式。这种日志操作模式不仅可用于保护例程失败,还可以用于保护介质损坏的情况。如果数据库管理员把日志设置为归档日志模式,则当后台进程在进行日志切换时,后台进程会自动将重做日志的内容复制到归档日志中。归档日志就是非活动重做日志的备份。
如现在Oracle数据库中有四个日志组,日志序列号分别为11、12、13、14。当数据库事务变化写满第一个日志组文件(序列号为11) 时,后台进程就会切换到第二个日志组中(序列号为12)。不过在这个切换之前,数据库有一个进程,会负责将第一个日志组中的文件内容复制到归档日志中去。依次类推。这就是归档日志模式与非归档日志模式最本质的区别。不过这个区别却给数据库安全性带来了很大的变化。
如当日志序列号为28时出现了数据文件的错误或者服务器硬盘损坏的事故时,因为日志文件中记录了从数据库备份以来所有的数据变化情况。而且这些日志文件与数据库备份文件存储在其他媒体中,那么数据库管理员就可以通过这些资料,把数据库恢复到介质损坏时(即日志文件序列号为28)的数据。从保护数据库数据的角度讲,这是一个接近于比较理想的状态了。
若把非归档模式与归档模式进行对比的话,可以发现归档模式有如下的特点。
一是当出现介质损坏(如硬盘损坏或者意外删除数据文件)或者出现例程失败(如服务器突然断电)时,数据库管理员可以凭借归档日志文件来防止丢失数据。而非归档模式则往往只能够应对例程失败的情况。所以,其应用范围要比非归档模式大的多。
二是数据备份的限制条件。正如上面所说的,如果数据库处于非归档模式,则对数据库进行备份时,要先用SHUTDOWNNORMAL等命令关闭数据库。而处于归档模式的时候,则当数据库处于Open状态时,数据库管理员仍然可以备份数据库,而且不会影响数据库的正常使用。除了数据库备份两者有本质上的差异之外,在数据库恢复上也有很大的差别。若数据库采用归档日志模式,不仅可以执行完全恢复,而且在归档日志文件的帮助下,还可以将数据库恢复到特定的点。从而当数据库出现意外故障时,最大限度的保护数据的安全性。
不过若采取归档模式的话,则必须要牺牲一定的磁盘空间。
三、如何选择合适的日志操作模式?
非归档模式只适用于例程失败时恢复数据,不能够用来保护介质损坏。即当数据库的数据文件意外损坏时,非归档模式没有应对之策。归档模式不仅可以用来保护例程失败,而且还可以在介质失败的时候,最大程度的恢复数据库的原有数据。此时,数据库管理员可以利用数据库备份文件、归档日志文件、重做日志文件等把数据库中的数据恢复到故障发生的那一时点。
既然归档操作模式与非归档操作模式各有各的特点,那么在什么时候采用归档日志模式为好,什么时候又该采用非归档模式呢?这个问题的答案,是公说公有理,婆说婆有理。恐怕争论个几年也没有一个固定的答案。对此,笔者就提一下自己的意见。这也不是标准答案,只是供大家参考。
首先要看数据库中数据变化的频繁程度。当数据库中数据变化比较少的时候,则最好采用非归档模式。相反,如果数据库中的数据变化比较频繁,如一些业务操作系统,则最好能够采用归档模式。
其次,要看企业对数据丢失的态度。如果企业对于数据安全要求比较高,如银行,不允许丢失任何数据,则最好能够采用归档日志模式。在数据库意外故障的时候,其可以帮助数据库管理员在最大程度上恢复数据。同理,当企业可以允许部分损坏数据的时候,则可以采用非归档模式,以节省切换日志组时的对日志文件备份的额外开销与磁盘空间。
再者,要看看数据库是否需要全天候运行。因为在非归档模式下,必须利用SHUTDOWNNORMAL等命令关闭数据库,才能过对数据库进行备份。这跟数据库全天候运行的要求是不符合的。而归档模式下,即使数据库出于OPEN状态,也可以对其进行备份,也不会影响数据库的正常运行。为此,若果数据库需要全天候运行的话,则最好采用归档模式。虽然数据库为此要付出一些额外的开销,笔者认为也是值得的。毕竟硬件投资有价,数据无价。
数据库管理员要根据企业的实际情况,选择合适的日志操作模式。从而让重做日志与归档日志真正成为Oracle数据库的保护伞。

데이터베이스 및 프로그래밍에서 MySQL의 위치는 매우 중요합니다. 다양한 응용 프로그램 시나리오에서 널리 사용되는 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1) MySQL은 웹, 모바일 및 엔터프라이즈 레벨 시스템을 지원하는 효율적인 데이터 저장, 조직 및 검색 기능을 제공합니다. 2) 클라이언트 서버 아키텍처를 사용하고 여러 스토리지 엔진 및 인덱스 최적화를 지원합니다. 3) 기본 사용에는 테이블 작성 및 데이터 삽입이 포함되며 고급 사용에는 다중 테이블 조인 및 복잡한 쿼리가 포함됩니다. 4) SQL 구문 오류 및 성능 문제와 같은 자주 묻는 질문은 설명 명령 및 느린 쿼리 로그를 통해 디버깅 할 수 있습니다. 5) 성능 최적화 방법에는 인덱스의 합리적인 사용, 최적화 된 쿼리 및 캐시 사용이 포함됩니다. 모범 사례에는 거래 사용 및 준비된 체계가 포함됩니다

MySQL은 소규모 및 대기업에 적합합니다. 1) 소기업은 고객 정보 저장과 같은 기본 데이터 관리에 MySQL을 사용할 수 있습니다. 2) 대기업은 MySQL을 사용하여 대규모 데이터 및 복잡한 비즈니스 로직을 처리하여 쿼리 성능 및 트랜잭션 처리를 최적화 할 수 있습니다.

InnoDB는 팬텀 읽기를 차세대 점화 메커니즘을 통해 효과적으로 방지합니다. 1) Next-Keylocking은 Row Lock과 Gap Lock을 결합하여 레코드와 간격을 잠그기 위해 새로운 레코드가 삽입되지 않도록합니다. 2) 실제 응용 분야에서 쿼리를 최적화하고 격리 수준을 조정함으로써 잠금 경쟁을 줄이고 동시성 성능을 향상시킬 수 있습니다.

MySQL은 프로그래밍 언어가 아니지만 쿼리 언어 SQL은 프로그래밍 언어의 특성을 가지고 있습니다. 1. SQL은 조건부 판단, 루프 및 가변 작업을 지원합니다. 2. 저장된 절차, 트리거 및 기능을 통해 사용자는 데이터베이스에서 복잡한 논리 작업을 수행 할 수 있습니다.

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 주로 데이터를 신속하고 안정적으로 저장하고 검색하는 데 사용됩니다. 작업 원칙에는 클라이언트 요청, 쿼리 해상도, 쿼리 실행 및 반환 결과가 포함됩니다. 사용의 예로는 테이블 작성, 데이터 삽입 및 쿼리 및 조인 작업과 같은 고급 기능이 포함됩니다. 일반적인 오류에는 SQL 구문, 데이터 유형 및 권한이 포함되며 최적화 제안에는 인덱스 사용, 최적화 된 쿼리 및 테이블 분할이 포함됩니다.

MySQL은 데이터 저장, 관리, 쿼리 및 보안에 적합한 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1. 다양한 운영 체제를 지원하며 웹 응용 프로그램 및 기타 필드에서 널리 사용됩니다. 2. 클라이언트-서버 아키텍처 및 다양한 스토리지 엔진을 통해 MySQL은 데이터를 효율적으로 처리합니다. 3. 기본 사용에는 데이터베이스 및 테이블 작성, 데이터 삽입, 쿼리 및 업데이트가 포함됩니다. 4. 고급 사용에는 복잡한 쿼리 및 저장 프로 시저가 포함됩니다. 5. 설명 진술을 통해 일반적인 오류를 디버깅 할 수 있습니다. 6. 성능 최적화에는 인덱스의 합리적인 사용 및 최적화 된 쿼리 문이 포함됩니다.

MySQL은 성능, 신뢰성, 사용 편의성 및 커뮤니티 지원을 위해 선택됩니다. 1.MYSQL은 효율적인 데이터 저장 및 검색 기능을 제공하여 여러 데이터 유형 및 고급 쿼리 작업을 지원합니다. 2. 고객-서버 아키텍처 및 다중 스토리지 엔진을 채택하여 트랜잭션 및 쿼리 최적화를 지원합니다. 3. 사용하기 쉽고 다양한 운영 체제 및 프로그래밍 언어를 지원합니다. 4. 강력한 지역 사회 지원을 받고 풍부한 자원과 솔루션을 제공합니다.

InnoDB의 잠금 장치에는 공유 잠금 장치, 독점 잠금, 의도 잠금 장치, 레코드 잠금, 갭 잠금 및 다음 키 잠금 장치가 포함됩니다. 1. 공유 잠금을 사용하면 다른 트랜잭션을 읽지 않고 트랜잭션이 데이터를 읽을 수 있습니다. 2. 독점 잠금은 다른 트랜잭션이 데이터를 읽고 수정하는 것을 방지합니다. 3. 의도 잠금은 잠금 효율을 최적화합니다. 4. 레코드 잠금 잠금 인덱스 레코드. 5. 갭 잠금 잠금 장치 색인 기록 간격. 6. 다음 키 잠금은 데이터 일관성을 보장하기 위해 레코드 잠금과 갭 잠금의 조합입니다.


핫 AI 도구

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

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

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

Clothoff.io
AI 옷 제거제

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

인기 기사

뜨거운 도구

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

SublimeText3 Linux 새 버전
SublimeText3 Linux 최신 버전

DVWA
DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

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