--DBMS_SCHEDULER 运行信息
select job_name,state,enabled,to_char(last_start_date,'yyyy-mm-dd hh24:mi:ss'), schedule_name
from dba_scheduler_jobs;
--DBMS_SCHEDULER运行成功与否信息
SELECT log_id, job_name, status,TO_CHAR(ACTUAL_START_DATE,'yyyy-mm-dd HH24:MI:ss') start_date,
           TO_CHAR (log_date, 'yyyy-mm-dd HH24:MI:ss') log_date
      FROM dba_scheduler_job_run_details
     WHERE job_name = 'GATHER_STATS_JOB'
     order by 4 DESC;
--查询执行时间情况
select t1.window_name,t1.repeat_interval,t1.duration from dba_scheduler_windows t1,dba_scheduler_wingroup_members t2
 where t1.window_name=t2.window_name and t2.window_group_name='MAINTENANCE_WINDOW_GROUP';
--修改执行时间
begin
dbms_scheduler.set_attribute('WEEKEND_WINDOW','REPEAT_INTERVAL','freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0');
dbms_scheduler.set_attribute('WEEKEND_WINDOW','DURATION','+002 00:00:00');
end;

一般来说，调优的第一手资料，很可能就是典型业务期的一个statspack报告，那么如何根据statspack报告来判断是哪些SQL消耗了最多的系统资源?哪些SQL是最需要调整的呢?这里给出了一个大致的优化思路。当然，思路是死的，人是活的，优化也需要随需应变。
　　一般来说，需要关注下面四种Top SQL
　　消耗最多CPU的(逻辑IO过多)
　　导致过多物理I/O的
　　执行次数较频繁的
　　执行时间较长的
　　我们知道，一个语句的响应时间有个很著名的公式：
　　响应时间=服务时间+等待时间
　　其中服务时间就是CPU为执行该语句花费的时间。
　　服务时间=分析时间+递归时间+执行时间
　　分析时间是CPU用于分析语句的时间，递归时间是CPU用于语句的递归SQL的时间，剩下的则就是CPU用于执行语句的真正时间了。
　　那么，上面的这些时间信息从哪里来的?Oracle提供的系统统计信息中就有部分的时间统计信息：
　　服务时间=CPU used by this session
　　分析时间=parse time cpu
　　递归时间=recursive cpu usage
　　那么，执行时间就可以根据上面三个统计信息计算得出：
　　执行时间=CPU used by this session – parse time cpu – recursive cpu usage
　　如果执行时间在整个响应时间中占较大的比例，那么下一步就是找出那些造成了最多逻辑IO的SQL语句，可以从statspack报告的SQL ordered by Gets部分找到。
　　如果分析时间在整个响应时间中占较大的比例，那么下一步就是查找哪些SQL分析过多，这在statspack报告中在SQL ordered by Parse Calls中列出。
　　如果等待时间在整个响应时间中占较大的比例，并且主要是块读取相关的等待时，下一步就是找出哪些SQL造成了过多的物理读，可以查看statspack报告中的SQL ordered by Reads部分。
　　那么，根据上面列出的一个简单的原则，我们需要关注三个关于CPU时间的统计信息: CPU used by this session, parse time cpu和recursive cpu usage，以及top5等待事件中和IO相关的等待时间。如果是其他的一些等待事件出现在Top5中，那么可能需要根据不同的等待事件来分析原因了。然后优先调优时间消耗最多的相关SQL。
　　除了上面的SQL ordered by Gets(逻辑IO最多)，SQL ordered by Parse Calls(软解析过多)，SQL ordered by Reads(物理IO过多)，statspack还按照其他的一些方式列出了Top SQL，这些Top SQL在某些情况下都是需要给予特别关注的。比如：
　　SQL ordered by Executions 执行次数超过100的
　　SQL ordered by Sharable Memory 占用library cache超过1M的
　　SQL ordered by Version Count 子cursor超过20的
　　如果没有statspack，那么根据v$sysstat/v$sesstat中的统计信息，结合v$sql/v$sqlarea，一样可以得到相关的SQL。
　　v$sql对于每一个子cursor都有一行统计记录，而v$sqlarea则对同一个父cursor只有一行统计记录，也就是v$sqlarea是对v$sql按照父cursor进行group by后的一个结果。这两个视图中都有诸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列，和上面提到的statspack中列出Top SQL的条件对应。

DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-000a0002-00005420 68 440 X 65 496 S
TX-0001001b-00002b19 65 496 X 68 440 S
session 440: DID 0001-0044-000A2346 session 496: DID 0001-0041-000CBA54
session 496: DID 0001-0041-000CBA54 session 440: DID 0001-0044-000A2346
Rows waited on:
Session 496: obj – rowid = 00014282 – AAAUKCAAMAAAEZrAAA
(dictionary objn – 82562, file – 12, block – 18027, slot – 0)
Session 440: no row
Information on the OTHER waiting sessions:
Session 496:
pid=65 serial=58006 audsid=1896040 user: 88/VAS
O/S info: user: web_meg, term: unknown, ospid: , machine: ezg-web1
program: JDBC Thin Client
application name: JDBC Thin Client, hash value=2546894660
Current SQL Statement:
insert into TAB_XN_CONTENT_TEMP (key,content) values (:1,:2)
End of information on OTHER waiting sessions.
Current SQL statement for this session:
insert into TAB_XN_CONTENT_TEMP (key,content) values (:1,:2)
我一看到这个错误，有点不明白，oracle 的insert操作竟然导致表被锁，然后查找些资料终于有了眉目：
当ORACLE执行insert等DML语句时，会首先自动在所要操作的表上申请一个TM锁，当TM锁获得后，再自动申请TX类型的锁。当两个或多个会话在表的同一条记录上执行DML语言时，第一个会话在记录上加锁，其它的会话处于等待状态，一直到第一个会话提交后TX锁释放，其它的会话才可以加锁。考虑是因为两个insert语句同时试图向一个表中插入PK或unique值相同的数据，而造成其中会话被阻塞，等待其它会话提交或回滚，因而造成死锁。这种情况，只要其中任何一个session提交，另外一个就会报出ORA-00001：违反唯一性约束条件，死锁终止；或者其中一个session回滚，另外一个即可正常执行。
通过对这段话的理解，应该是一个会话插入了一条记录未提交，然后另外一个会话继续插入主键或者唯一索引列相同的记录，导致死锁的发生。
环境模拟：
在会话1中执行下面语句
CREATE TABLE t1(ID NUMBER);
ALTER TABLE t1 ADD primary key (ID);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
然后在会话2中执行下面语句
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
在会话3中查询死锁情况
通过上面模拟，重现了insert死锁现象，说明红色标注出来的文字的正确性

主要是使用DBMS_REDEFINITION包实现，我这里主要是实现一个由普通表转为分区表的处理
在线重定义的表自行验证，看该表是否可以重定义
EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE(user, ‘T_DEF’, DBMS_REDEFINITION.CONS_USE_PK);
–如果T_DEF表无主键，请添加上，不然会爆如下错误
begin DBMS_REDEFINITION.CAN_REDEF_TABLE(user, ‘T_DEF’, DBMS_REDEFINITION.CONS_USE_PK); end;
ORA-12089: cannot online redefine table “CHF”.”T_DEF” with no primary key
ORA-06512: at “SYS.DBMS_REDEFINITION”, line 137
ORA-06512: at “SYS.DBMS_REDEFINITION”, line 1479
ORA-06512: at line 2
执行表的在线重定义
EXEC DBMS_REDEFINITION.START_REDEF_TABLE(USER, ‘T_DEF’, ‘T_DEF_NEW’);
同步数据
exec dbms_redefinition.sync_interim_table(USER, ‘T_DEF’, ‘T_DEF_NEW’);
执行结束在线定义过程
EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE(user, ‘T_DEF’, ‘T_DEF_NEW’);
说明：
1、和使用交换分区的办法处理，这个是在线的，不用停业务
2、在线重定义处理后，原表中的数据不会被清空，可能需要额外的空间
3、处理速度没有直接使用交互分区快

oracle权限体系中有个default role，比较难以理解。下面用实例说明一下作用。
我们可以给某个用户分配一些角色，比如role r1,r2,r3,r4，而其中可以将某些角色比如r1设置为default role，其他的不设置成default role，这样，当该用户登录时，自动具有default role中所包含的权限，其他的角色所具有的权限要通过set role 角色来获得。
下面我们举个例子：
（1）sys用户作为sysdba登录，创建4个角色：
create role r1;
create role r2 identified by r2;
create role r3 identified by r3;
create role r4 identified by r4;
（2）sys用户赋予这四个角色对应的权限：
grant create session to r1;
grant select on hr.test to r2;（这里hr.test是我新创建的一个表，里面有ID和name两列）
grant update(name) on hr.test to r3;
grant insert on hr.test to r3;
grant delete on hr.test to r4;
（3）sys用户创建一个用户u3
create user u3 identified by u3;
（4）将角色r1,r2,r3,r4赋予用户u3
grant r1,r2,r3,r4 to u3;
在修改用户u3的默认角色前，r1,r2,r3,r4 角色均为u3的 default role，以u3用户登录，查询、增删改hr.test，都没有问题。
（5）现在sys用户修改用户u3的default role，仅将r1作为u3的默认角色：
alter user u3 default role r1; –此时将覆盖原来的设置，u3 的default role =r1，仅仅有登录权限。
（6）用户u3 log off ，然后再log on，进去后发现，
查询、增删改hr.test都不能进行。
（7） 用户自己打开role权限
set role r2 identified by r2;
这时执行 select * from hr.test,发现没有问题。增删改不行。
将对应的角色打开：
set role r3 identified by r3;
此时修改和插入记录没有问题，但是select * from hr.test 确发现不行了。证明此时用户所属的角色仅仅是默认角色r1，和刚刚打开的角色r3，而r2被set role r3 identified by r3;覆盖掉了。
那要同时有r2，r3，r4的权限怎么办呢？
set role r2 identified by r2,r3 identified by r3,r4 identified by r4。此时就同时对hr.test可以进行查询，增删改了。
不过set role 的效果是临时的，只是当前session有效，其他的session无效，当结束当前session后再登录，又只有default role 的权限了。

SQL> @?/rdbms/admin/awrrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
———– ———— ——– ————
3393548168 XFF 1 xff
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter ‘html’ for an HTML report, or ‘text’ for plain text
Defaults to ‘html’
输入 report_type 的值: html
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
———— ——– ———— ———— ————
* 3393548168 1 XFF xff XIFENFEI-PC
Using 3393548168 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing without
specifying a number lists all completed snapshots.
输入 num_days 的值: 2[天数]
Listing the last 2 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
———— ———— ——— —————— —–
xff XFF 119 22 4月 2011 21:22 1
120 22 4月 2011 21:40 1
121 22 4月 2011 21:40 1
122 22 4月 2011 22:02 1
123 22 4月 2011 22:30 1
124 22 4月 2011 23:00 1
125 22 4月 2011 23:30 1
126 23 4月 2011 00:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值: 120[起始快照号]
Begin Snapshot Id specified: 120
输入 end_snap 的值: 125[结束快照号]
End Snapshot Id specified: 125
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_120_125.html. To use this name,
press to continue, otherwise enter an alternative.
输入 report_name 的值: xifenfei.html[文件名]
<enter>[回车执行]
查看生成awr文件

1、添加分区
1.1）增加分区(add partition)
语法是：alter table xxx add partition…
Alter table t_range add partition p5 values less than (50) [tablespace users];
–50 要大于之前分区的所有值
Alter table t_list add partition p5 values (7,8,9) [tablespace users];
–7,8,9均不能在之前分区中出现
Alter table t_hash add partition [p5] [tablespace users];
–添加hash分区
1.2)添加子分区
Alter table xxx modify partition p1 add subpartition …
增加RANGE-HASH子分区
ALTER TABLE diving MODIFY PARTITION locations_us
ADD SUBPARTITION us_locs5 TABLESPACE us1;
说明：Range,list增加分区不会影响索引(包括global 跟local)，HASH增加分区会让数据重新分配，产生IO，如果不指定update indexes 选项则会导致有数据移动的索引unusable，需要重新编译。
当然，我们说的对索引的影响都是在表中有数据的情况下，没数据当然影响不到索引了。
2、合并分区
2.1）HASH分区或子分区
Alter table xxx coalesce partion [update indexes];
Alter table xxx modify partition p1 coalesce subpartition;
合并一次会减少一个分区(最少能减少到1个)，数据重新分配，产生IO，有数据移动的索引失效(如果不指定update indexes的话).
2.2）非HASH分区
Alter table xxx merge partitions/subpartitions p1,p2 into partiton/subpartition p3 [TABLESPACE tablespace_name];
表分区必须是相邻的。
跟COALESCE一样，会产生IO,数据量大的话，IO也是相当大的。
同样可以用UPDATE INDEXES 避免索引失效
alter table dinya_test merge partitions part_01,part_02 into partition part_02;
3、删除分区(drop partition)
Alter table xxx drop partition ppp;
删除子分区：
Alter table xxx drop subpartition ppp;
此功能hash不支持。同时要注意，删除分区会同时删除该分区内数据。
同样，如果不指定update indexes的话该操作会导致GLOBAL索引失效，而LOCAL不会，因为对应的LOCAL索引分区也被删除了嘛，其他分区的LOCAL不会受到影响。
4、交换分区(exchange partition)
Alter table tb1 exchange partition/subpartition p1 with table tb2;
据说是采用了更改数据字典的方式，所以速度比较快。
可以是分区跟非分区表交换，子分区跟非分区表交换，组合分区跟分区表交换。
alter table t_partition_range exchange partition t_range_p2
with table t_partition_range_tmp;
将t_range_p2与t_partition_range_tmp的数据互迁移
注意点：
涉及交换的两表之间表结构必须一致，除非附加with validation子句;
如果是从非分区表向分区表做交换，非分区表中的数据必须符合分区表中指定分区的规则，除非附加without validation子句;
如果从分区表向分区表做交换，被交换的分区的数据必须符合分区规则，除非附加without validation子句;
Global索引或涉及到数据改动了的global索引分区会被置为unusable，除非附加update indexes子句。
5、拆分分区
功能与MERGE PARTITIONS相反。通常我们会用来拆分MAXVALUE/DEFAULT分区。
Range partition:
Alter table xxx split partition/subpartition p1 at (15) into (partition/subpartition p1_new1,partition/subpartition p1_new2);
List partition:
Alter table xxx split partition/subpartition p1 values(15,16) into (partition/subpartition p1_new1,partition/subpartition p1_new2);
原分区中符合新值定义的记录会存入第一个分区,其他存入第二个分区,当然,在新分区后面可以指定属性,比如TABLESPACE。
HASH分区不适用。
会产生IO
同样，可用update indexes 来避免索引失效
alter table timestamps split partition p1 at (to_date(‘2003-01-01′,’yyyy-mm-dd’))into (partition px tablespace ts3, partition py tablespace ts3);
将P1分区拆分成PX，PY两个分区，分界点是to_date(‘2003-01-01′,’yyyy-mm-dd’)
6、修改LIST分区—ADD VALUES
Alter table xxx modify partition/subpartition p1 add values(7,9);
要注意的是，增加的VALUES不能在其他分区列的VALUES值中存在，也不能在DEFAULT分区(如果有的话)中有相应VALUES.
不会影响索引
7、修改LIST 分区—DROP VALUES
Alter table xxx modify partition/subpartition p1 drop values(8,9);
同样,删除的values 不能存在记录.
不会影响索引
8、截断分区
跟TRUNCATE TABLE一样，截断该分区内的数据。
Alter table xxx truncate partition/subpartition p1;
同样，可用update indexes 来避免索引失效
9、移动分区
Alter table xxx move partition/subpartition p1 …;
有些功能比如改变分区表空间,modify partition就做不到，此时就可以用move partition来做
Alter table tab move partition p_tab tablespace tbl update indexes;
可用update indexes 来避免索引失效
10、修改分区默认属性(modify default attributes)
修改表属性：alter table xxx modify default attributes …
修改分区属性(适用于组合分区)：alter table xxx modify default attributes for partition p1 …
只对以后添加的分区产生影响，适用于所有分区，其中hash分区只能修改表空间属性。
如：Alter table xxx modify default attributes tablespace users;
建立Oracle分区表

显示数据库所有分区表的信息：
select * from DBA_PART_TABLES;
显示表分区信息/显示数据库所有分区表的详细分区信息：
select * from DBA_TAB_PARTITIONS
显示子分区信息/显示数据库所有组合分区表的子分区信息：
select * from DBA_TAB_SUBPARTITIONS
显示分区列/显示数据库所有分区表的分区列信息：
select * from DBA_PART_KEY_COLUMNS
显示子分区列/显示数据库所有分区表的子分区列信息：
select * from DBA_SUBPART_KEY_COLUMNS
显示数据库所有分区表索引的信息：
SELECT * FROM dba_part_indexes;

一、默认情况下
–创建t_orascn测试表
SQL> create table t_orascn(id number);
Table created
–插入两条数据
SQL> insert into t_orascn values(1);
1 row inserted
SQL> insert into t_orascn values(2);
1 row inserted
SQL> commit;
Commit complete
–查询ora_rowscn和相关数据
SQL> select ora_rowscn,id from t_orascn;
ORA_ROWSCN ID
———- ———-
559036 1
559036 2
–更新其中一条数据
SQL> update t_orascn set id=2 where rownum=1;
1 row updated
SQL> commit;
Commit complete
–再查询ora_rowscn和相关数据
SQL> select ora_rowscn,id from t_orascn;
ORA_ROWSCN ID
———- ———-
559669 2
559669 2
–查询更详细信息
SQL> Select versions_xid,versions_startscn,versions_endscn,
2 DECODE(versions_operation,’I’,’Insert’,’U’,’Update’,’D’,’Delete’, ‘Original’) “Operation”, id from t_orascn versions between scn minvalue and maxvalue;
VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN Operation ID
—————- —————– ————— ——— ———-
0500180055010000 559669 Update 2
02001C0068010000 559036 Insert 2
02001C0068010000 559036 559669 Insert 1
–查询操作时间
SQL> select to_char(scn_to_timestamp(ora_rowscn),’yyyy-mm-dd hh24:mi:ss’),id from t_orascn;
TO_CHAR(SCN_TO_TIMESTAMP(ORA_R ID
—————————— ———-
2011-04-11 00:01:12 2
2011-04-11 00:01:12 2
–查询数据详细操作时间
SQL> Select versions_xid,to_char(scn_to_timestamp(versions_startscn),’yyyy-mm-dd hh24:mi:ss’),versions_endscn,DECODE(versions_operation,’I’,’Insert’,’U’,’Update’,’D’,’Delete’, ‘Original’) “Operation”, id from t_orascn versions between scn minvalue and maxvalue;
VERSIONS_XID TO_CHAR(SCN_TO_TIMESTAMP(VERSI VERSIONS_ENDSCN Operation ID
—————- —————————— ————— ——— ———-
0500180055010000 2011-04-11 00:01:12 Update 2
02001C0068010000 2011-04-10 23:59:03 Insert 2
02001C0068010000 2011-04-10 23:59:03 559669 Insert 1
–结论：ora_rowscn在没有默认情况下，如果数据库块中的任何一条记录发生改变，该块中的所有记录的ora_rowscn中对应的scn值都改变
二、创建表含有rowdependencies测试
–创建测试表t_orascn_b
SQL> create table t_orascn_b(id number) rowdependencies;
Table created
SQL> insert into t_orascn_b values(1);
1 row inserted
SQL> insert into t_orascn_b values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select ora_rowscn,id from t_orascn_b;
ORA_ROWSCN ID
———- ———-
560532 1
560532 2
SQL> insert into t_orascn_b values(3);
1 row inserted
SQL> select ora_rowscn,id from t_orascn_b;
ORA_ROWSCN ID
———- ———-
560532 1
560532 2
3
SQL> commit;
Commit complete
SQL> select ora_rowscn,id from t_orascn_b;
ORA_ROWSCN ID
———- ———-
560532 1
560532 2
560555 3
–说明一点：没有提交ora_rowscn不改变(update)或者不存在（insert）
SQL> update t_orascn_b set id=10 where id<2; 1 row updated SQL> commit;
Commit complete
SQL> select to_char(scn_to_timestamp(ora_rowscn),’yyyy-mm-dd hh24:mi:ss’),id from t_orascn_b;
TO_CHAR(SCN_TO_TIMESTAMP(ORA_R ID
—————————— ———-
2011-04-11 00:15:38 10
2011-04-11 00:12:37 2
2011-04-11 00:13:28 3
SQL>
SQL> Select versions_xid,versions_startscn,versions_endscn,
2 DECODE(versions_operation,’I’,’Insert’,’U’,’Update’,’D’,’Delete’, ‘Original’) “Operation”, id from t_orascn_b versions between scn minvalue and maxvalue;
VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN Operation ID
—————- —————– ————— ——— ———-
0800290054010000 560614 Update 10
0500130056010000 560555 Insert 3
0A00090001010000 560532 Insert 2
0A00090001010000 560532 560614 Insert 1
SQL> Select versions_xid,to_char(scn_to_timestamp(versions_startscn),’yyyy-mm-dd hh24:mi:ss’),versions_endscn,DECODE(versions_operation,’I’,’Insert’,’U’,’Update’,’D’,’Delete’, ‘Original’) “Operation”, id from t_orascn_b versions between scn minvalue and maxvalue;
VERSIONS_XID TO_CHAR(SCN_TO_TIMESTAMP(VERSI VERSIONS_ENDSCN Operation ID
—————- —————————— ————— ——— ———-
0800290054010000 2011-04-11 00:15:38 Update 10
0500130056010000 2011-04-11 00:13:28 Insert 3
0A00090001010000 2011-04-11 00:12:37 Insert 2
0A00090001010000 2011-04-11 00:12:37 560614 Insert 1
–结论：如果创建表时指定了rowdependencies，则ora_rowscn是以行为单位变化，而不是块

CONTROL_FILE_RECORD_KEEP_TIME
表示控制文件里可重复使用的记录所能保存的最小天数。如果新增加一条记录到控制文件可以重复使用的部分，这时最老的记录尚没有超出最小保留天数，那么记录将控制文件的这一部分将扩展。如果将该参数设置为0，那么控制文件可以重复使用的部分将永远不会扩展。
注意，这个参数只应用于控制文件中可循环利用的部分，如归档日志文件，各种备份记录。不应用于诸如数据文件，表空间，重做线程等，这些内容只有当其从对应的表空间中删除后才能重用。
LOG_ARCHIVE_LOCAL_FIRST
specifies when the archiver processes (ARCn) transmit redo data to remote standby database destinations.（11g中不建议使用）可选值：true/false
true
Directs the ARCn process to transmit redo data after the online redo log file has been completely and successfully archived to at least one local destination. This is the default value.
Because the online redo log files are archived locally first, the LGWR process reuses the online redo log files much earlier than would be possible if the ARCn processes archived to the standby database concurrently with the local destination. This behavior is useful when archiving to remote destinations that use a slow network connection, such as a long-distance wide area network (WAN).
false
Directs the ARCn process to transmit redo data at the same time the online redo log file is archived to the local destinations. This results in redo data being promptly dispatched to the remote standby database destination.
Setting LOG_ARCHIVE_LOCAL_FIRST to false is most useful for faster network connections, such as high-speed local area networks (LAN).