强制日志记录：数据库保障的核心——force_logging (数据库的force_logging)
在数据库管理系统中，日志记录是保障数据完整性、可恢复性、可靠性的重要手段。通过在数据库操作过程中记录关键的事务信息，特别是变更操作，可以在系统出现异常情况时，帮助管理员进行数据恢复，避免数据库出现不可预测的错误。而强制日志记录（force_logging）则是一项数据库管理的重要保障措施，保证数据库系统执行变更操作时必须记录日志信息，其重要性不言而喻。
什么是强制日志记录？
强制日志记录是一种数据库配置设置，在Oracle数据库管理系统中得到广泛应用。强制日志记录的主要作用是确保数据库执行的变更操作一定会被记录在系统日志中，即使在异常情况下也不例外。在启用了强制日志记录功能的系统中，数据库会禁止一些不安全的操作，如禁止直接修改数据文件、禁止使用 noarchivelog 模式，保证所有的操作都能够被安全记录，防止数据丢失或损坏。
为什么需要强制日志记录？
在管理数据库时，如果没有强制日志记录功能，就会出现数据丢失、数据损坏等问题，导致数据库系统出现意外的错误，给企业带来重大损失。例如，如果在事务处理中遇到硬件崩溃，若有些修改还未写入日志，那么这些修改是无法恢复的。有了强制日志记录功能，就可以保证所有事务的日志信息都被记录下来，避免了数据丢失和损坏的问题，保证了数据库的可靠性和可恢复性。
强制日志记录和日志模式
强制日志记录和日志模式紧密相关，日志模式是控制数据库记录数据更改记录的参数。Oracle数据库中，日志模式可分为ARCHIVEDLOG和NOARCHIVEDLOG两种类型。在ARCHIVEDLOG日志模式下，所有的事务日志都会被写入归档日志中，即使发生了崩溃，操作记录也不会丢失，可以通过归档日志恢复数据。而在 NOARCHIVEDLOG 日志模式下，所有的日志记录会写入在线重做日志中，但不会被归档，一旦出现故障，其中的操作记录就会有一定概率丢失。因此，在强制日志记录功能开启的 Oracle 数据库中，日志模式必须设置为 ARCHIVEDLOG。
强制日志记录对数据库性能的影响
强制日志记录会对数据库的写入操作产生一定的负载，通过不断写入实时日志记录的方式，保证了数据库的数据安全性和可靠性。但同时，这种功能也会对数据库的性能产生一定的影响。强制日志记录需要在每一个事务提交时都写入实时日志记录，多个写入操作必然会增加数据库的IO读写操作、磁盘空间占用以及写操作的时间消耗。
在大型企业或复杂应用的数据库系统中，如果需要开启强制日志记录功能，那么管理员需要在评估风险和性能需求的基础上进行权衡和取舍。在性能和可靠性之间寻找平衡点，确保数据的安全、完整和可靠。
强制日志记录是数据库系统保障数据安全、完整和可靠的重要手段之一。在Oracle数据库管理系统中，启用强制日志记录功能可以避免数据丢失、数据损坏等问题，确保所有的操作都能够被安全记录。但同时，也需要注意其对数据库性能的影响，并在正式开启前进行风险评估和性能优化的权衡。强制日志记录是数据库保障的核心之一，管理员应该在管理数据库时认真对待该功能，确保数据的可靠性、完整性和可恢复性。
相关问题拓展阅读：
oracle12c怎么打开ome
关于Forced Logging模式有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。
如果在执行force logging时有nologging之类的语句在执行，则force logging会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)
打开force logging
SQL > alter database force logging;
关闭force logging
SQL > alter database no force logging;
查看force logging的状态：
SQL > select FORCE_LOGGING from v$database;
2关于主备库的密码
密码文件位置$ORACLE_HOME/dbs/orapwSID，主备库的密码必须要一致，否则可能出现日志无法传输故障，更好是使用scp传过去较为方便。
3关于listener.ora和tnsnames.ora
listener.ora为数据库的监听配置文件，tnsnames.ora为网络服务名配置文件
修改listener.ora是需要重启监听程序，而tnsnames.ora是不需要重森衡启的，我们可以使用默认的listener.ora
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521)) ) )ADR_BASE_LISTENER = /opt/oracle
以上是动态注册，如果是静态注册的话，则是
SID_LIST_LISTENER =(SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /opt/oracle/product/11.2.0/db_1) (PROGRAM = extproc) ) (SID_DESC = (GLOBAL_DBNAME = db1) (ORACLE_HOME = /opt/oracle/product/11.2.0/db_1) (SID_NAME = db1) ) )
tnsnames.ora则只需要添加服务名
(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db1) ) )db2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = db2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db2) ) )
以上按照自己的实际情况进行修改以上配置好了，就可以相互的tnsping db1或tnsping db2进行测试。
4参数文件说明
参数文件说明：增加以下参数，如果在初始化参数已经有配置，则看需要做相应的修改。
1、与主库角色相关的初始化参数说明：
DB_NAME注意保持同一个Data Guard环境中所吵春裂有数据库DB_NAME相同。DB_UNIQUE_NAME为每一个数据库指定一个唯一的名称,以标示同一个dataguard环境中不同的数据库。
LOG_ARCHIVE_CONFIG 该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含主库db及备库db)，以逗号分隔。
例如：LOG_ARCHIVE_CONFIG=’DB_CONFIG=(db1,db22)’LOG_ARCHIVE_DEST_n 归档文件的生成路径。升闭
该参数非常重要,dataguard就是通过这里的设置传输日志的。LOG_ARCHIVE_DEST_STATE_n指定参数值为ENABLE，标示对应的LOG_ARCHIVE_DEST_n参数是否有效。
REMOTE_LOGIN_PASSWORDFILE推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。如果不同日志传输会失败。数据库默认是EXCLUSIVE,一般不用修改。LOG_ARCHIVE_FORMAT指定归档文件格式。一般也不用修改，保持默认即可。
2、以下参数为备库角色相关的参数，建议在主库的初始化参数中也进行设置，这样在主备库角色相互转换后不需要做修改dataguard也能正常运行。
FAL_SERVER 指定备库到主数据库的连接服务名，FAL_SERVER = orcl2日志所在服务器。FAL_CLIENT 指定主库到备库的连接服务名，FAL_CLIENT = orcl日志接收客户端。STANDBY_FILE_MANAGEMENT如果主库的数据文件发生修改（如新建，重命名等）则按照本参数的设置在备库中做相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理。
例如：STANDBY_FILE_MANAGEMENT=AUTO下面开始修改主库的初始化参数。
db_name参数已经设置，不用修改SQL> alter system set db_unique_name =’db1’ scope=spfile;SQL> alter system set log_archive_config=’dg_config=(db1,db2)’ scope=spfile;
—这里的db1和db2为db_unique_name
SQL> alter system set log_archive_dest_1=’location=/opt/oracle/flash_recovery_area’ scope=spfile;
–/opt/oracle/flash_recovery_area为本地的归档目录，需要手动创建该目录，当然也可以指定别的路径。注意oracle账号对该目录又可读写的权限。
SQL> alter system set log_archive_dest_state_1=enable scope=spfile;
–这个通常不用修改，系统默认的就是enable。
SQL>alter system set log_archive_dest_2=’service=db2 valid_for=(online_logfiles,primary_role) arch async NOAFFIRM db_unique_name=db2′ scope=spfile;
这里的service为主库连接到备库的服务名，后面会在tnsnames.ora文件中配置valid_for参数说明这个归档日志目的地在本数据库为主库的角色下才需要把online_logfile传输到备库去。
arch async NOAFFIRM说明的是同步的方式，同步的方式有三种:更大保护，更大性能，更大可用。
SQL> alter system set log_archive_dest_state_2=enable scope=spfile;
以上修改的是作为主库角色需要的参数，为了方便以后主备库切换，建议在主库中也配置作为备库角色的相关参数。
SQL> alter system set fal_server=db2 scope=spfile;
SQL> alter system set fal_client=db scope=spfile;
SQL> alter system set standby_file_management=auto scope=spfile;
生成静态参数文件，以备后面给备库使用。
SQL> create pfile from spfile;重新启动主库，使参数生效。
5DataGuard启动停止及维护
DataGuard停止：先主后备
DataGuard启动：先备后主
6DataGuard日常监控视图
1、主库查看日志归档路径是否可用，如果远程归档目录不可用则error会显示错误信息
SQL> select dest_name,status,error from v$archive_dest;
DEST_NAME STATUS ERROR——LOG_ARCHIVE_DEST_1 VALIDLOG_ARCHIVE_DEST_2 VALIDLOG_ARCHIVE_DEST_3 INACTIVELOG_ARCHIVE_DEST_4 INACTIVELOG_ARCHIVE_DEST_5 INACTIVELOG_ARCHIVE_DEST_6 INACTIVELOG_ARCHIVE_DEST_7 INACTIVELOG_ARCHIVE_DEST_8 INACTIVELOG_ARCHIVE_DEST_9 INACTIVELOG_ARCHIVE_DEST_10 INACTIVE10 rows selected.
如上记录则代表备库归档日志目录有效且正常。
2、查询数据库的主备角色，以及当前DataGuard的运行模式，在主备查询结果不同
主库：
SQL> select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;DATABASE_ROLE LOG_MODE PROTECTION_MODE PROTECTION_LEVEL-PRIMARY ARCHIVELOG MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
备库：
SQL> select database_role,LOG_MODE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;DATABASE_ROLE LOG_MODE PROTECTION_MODE PROTECTION_LEVEL-PHYSICAL STANDBY ARCHIVELOG MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
3、获取归档日志的应用情况，主备库结果不同。在主库上对于每个归档文件会有2条记录
SQL > select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;
备库:
/opt/oracle/flash_recovery_area/1_11_.dbf 11 YES/opt/oracle/flash_recovery_area/1_12_.dbf 12 YES/opt/oracle/flash_recovery_area/1_13_.dbf 13 YES/opt/oracle/flash_recovery_area/1_14_.dbf 14 YES/opt/oracle/flash_recovery_area/1_15_.dbf 15 YES/opt/oracle/flash_recovery_area/1_16_.dbf 16 YES/opt/oracle/flash_recovery_area/1_17_.dbf 17 YES/opt/oracle/flash_recovery_area/1_18_.dbf 18 YES/opt/oracle/flash_recovery_area/1_19_.dbf 19 YES/opt/oracle/flash_recovery_area/1_20_.dbf 20 YES/opt/oracle/flash_recovery_area/1_21_.dbf 21 YES/opt/oracle/flash_recovery_area/1_22_.dbf 22 YES/opt/oracle/flash_recovery_area/1_23_.dbf 23 YES/opt/oracle/flash_recovery_area/1_24_.dbf 24 IN-MEMORY
ORACLE控制文件创建
创建控制文件需模顷要在nomount状态下，你液携这闹码伏个错误说明你在mount下，shutdown immediate关闭数据库，然后startup nomount，再重建控制文件。
你的控制文件比你的数据文件要旧，也就是说你的控制文件不是最新的，而是你备份的控制文件。
你要恢复的话，是要看情况的，前提是你的数据库必须是运行在归档模式野段，并且归档日志都还存在
这些都有的话，你只需要执行嫌脊没recover database until cancel 后，在输入auto，ORACLE 会自动的为你做数芹纳据库恢复了。
Oracle DBA神器：PRM-DUL灾难恢复工具可以直接从这种受损的Oracle数据库中将数据拯救出来。
当你的数据库因为ORA-00600/ORA-07445或其他ORA-报错，或丢失关键的system表空间数据文件，或A diskgroup损坏时均可以考虑采用PRM-DUL来碧陪亩做恢复。PRM-DUL采用独创的DataBridge恢复技术，直接从数据文件中抽取数据悔森后可以像DBLINK那样直接插入到新建数据库中，而无需数据落地成为乱颤DMP文件占用空间。
控制文件唯姿有没有备份的？ 我以前虚余遇到这个错误是因为数据文件路径改变了，导致差山滚这个ORA-01110错误，后来通过alter database rename file ‘旧路径’ to’新路径’ 更改后，就好了。
数据库的force_logging的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库的force_logging,强制日志记录：数据库保障的核心——force_logging,oracle12c怎么打开ome,ORACLE控制文件创建的信息别忘了在本站进行查找喔。
