在天外天烤鸭店有模有样的看我们吃烤鸭

By sandeep makol

Yong Huang shared a link: “Took me a while to find the orig author of “Understanding the SCN”. It’s Geoff Ingram, in his 2002 book “High-performance Oracle”. You can see a paragraph on books.google.com. Shame on the plagiarist at http://www.dbapool.com/articles/1029200701.html.”

this is full text.

Understanding the SCN

In order to understand how Oracle performs recovery, it’s first necessary to understand Oracle’s SCN in terms of the various places where it can be stored and how it’s used for instance and media recovery.

The SCN is an internal number maintained by the database management system (DBMS) to log changes made to a database. The SCN increases over time as changes are made to the database by Structured Query Language (SQL). By understanding how the SCN is used, you can understand how Oracle recovery works. Oracle9i enables you to examine the current SCN using the following SQL:

SQL> select dbms_flashback.get_system_change_number from dual;

Whenever an application commits a transaction, the log writer process (LGWR) writes records from the redo log buffers in the System Global Area (SGA) to the online redo logs on disk. LGWR also writes the transaction’s SCN to the online redo log file. The success of this atomic write event determines whether your transaction succeeds, and it requires a synchronous (wait-until-completed) write to disk.

Note: The need for a synchronous write upon commit is one of the reasons why the online redo log can become a bottleneck for applications and why you should commit as infrequently as is practical. In general, Oracle writes asynchronously to the database datafiles for performance reasons, but commits require a synchronous write because they must be guaranteed at the time they occur.

SCN and Checkpoints:

A checkpoint occurs when all modified database buffers in the Oracle SGA are written out to datafiles by the database writer (DBWn) process. The checkpoint process (CKPT) updates all datafiles and control files with the SCN at the time of the checkpoint and signals DBWn to write out the blocks. A successful checkpoint guarantees that all database changes up to the checkpoint SCN have been recorded in the datafiles. As a result, only those changes made after the checkpoint need to be applied during recovery. Checkpoints occur automatically as follows:

• Whenever a redo log switch takes place
• Whenever the time set by the LOG_CHECKPOINT_TIMEOUT initialization parameter is reached
• Whenever the amount of redo written reaches the number of bytes associated with the LOG_CHECKPOINT_INTERVAL

Typically, LOG_CHECKPOINT_INTERVAL is chosen so that checkpoints only occur on log switches. Oracle stores the SCN associated with the checkpoint in four places: three of them in the control file and one in the datafile header for each datafile.

The System Checkpoint SCN:

After a checkpoint completes, Oracle stores the system checkpoint SCN in the control file. You can access the checkpoint SCN using the following SQL:

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
——————–
292767

The Datafile Checkpoint SCN:

After a checkpoint completes, Oracle stores the SCN individually in the control file for each datafile. The following SQL shows the datafile checkpoint SCN for a single datafile in the control file:

SQL> select name,checkpoint_change# from v$datafile where name like ‘%users01%’;
NAME                                  CHECKPOINT_CHANGE#
———————————– ——————–
/u02/oradata/OMFD1/users01.dbf                  292767

The Start SCN:

Oracle stores the checkpoint SCN value in the header of each datafile. This is referred to as the start SCN because it is used at instance startup time to check if recovery is required. The following SQL shows the checkpoint SCN in the datafile header for a single datafile:

SQL> select name,checkpoint_change# from v$datafile_header where name like ‘%users01%’;
NAME                                  CHECKPOINT_CHANGE#
———————————– ——————–
/u02/oradata/OMFD1/users01.dbf                  292767

The Stop SCN:

The stop SCN is held in the control file for each datafile. The following SQL shows the stop SCN for a single datafile when the database is open for normal use:

SQL> select name,last_change# from v$datafile where name like ‘%users01%’;
NAME                                LAST_CHANGE#
———————————– ————
/u02/oradata/OMFD1/users01.dbf

During normal database operation, the stop SCN is NULL for all datafiles that are online in read-write mode. SCN Values while the Database Is Up Following a checkpoint while the database is up and open for use, the system checkpoint in the control file, the datafile checkpoint SCN in the control file, and the start SCN in each datafile header all match. The stop SCN for each datafile in the control file is NULL. SCN after a Clean Shutdown After a clean database shutdown resulting from a SHUTDOWN IMMEDIATE or SHUTDOWN NORMAL of the database, followed by STARTUP MOUNT, the previous queries on v$database and v$datafile return the following:

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
——————–
293184

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like ‘%user%’;
NAME                                  CHECKPOINT_CHANGE#   LAST_CHANGE#
———————————– ——————– ————–
/u02/oradata/OMFD1/users01.dbf                  293184         293184

SQL> select name,checkpoint_change# from v$datafile_header where name like ‘%users01%’;
NAME                                                   CHECKPOINT_CHANGE#
———————————– ——————–
/u02/oradata/OMFD1/users01.dbf                  293184

During a clean shutdown, a checkpoint is performed and the stop SCN for each datafile is set to the start SCN from the datafile header. Upon startup, Oracle checks the start SCN in the file header with the datafile checkpoint SCN. If they match, Oracle checks the start SCN in the datafile header with the datafile stop SCN in the control file. If they match, the database can be opened because all block changes have been applied, no changes were lost on shutdown, and therefore no recovery is required on startup. After the database is opened, the datafile stop SCN in the control file once again changes to NULL to indicate that the datafile is open for normal use.

SCN after an Instance Crash

The previous example showed the behavior of the SCN after a clean shutdown. To demonstrate the behavior of the checkpoints after an instance crash, the following SQL creates a table (which performs an implicit commit) and inserts a row of data into it without a commit:
create table x(x number) tablespace users;

insert into x values(100);

If the instance is crashed by using SHUTDOWN ABORT, the previous queries on v$database and v$datafile return the following after the database is started up in mount mode:

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
——————–
293185

SQL> select name,checkpoint_change#,last_change# from v$datafile where name like ‘%users01%’;

NAME                                  CHECKPOINT_CHANGE#   LAST_CHANGE#
———————————– ——————– ————–
/u02/oradata/OMFD1/users01.dbf                  293185

SQL> select name,checkpoint_change# from v$datafile_header where name like ‘%users01%’;
NAME                                  CHECKPOINT_CHANGE#
———————————– ——————–
/u02/oradata/OMFD1/users01.dbf                  293185

In this case, the stop SCN is not set, which is indicated by the NULL value in the LAST_CHANGE# column. This information enables Oracle, at the time of the next startup, to determine that the instance crashed because the checkpoint on shutdown was not performed. If it had been performed, the LAST_CHANGE# and CHECKPOINT_CHANGE# values would match for each datafile as they did during a clean shutdown. If an instance crashes at shutdown, then instance crash recovery is required the next time the instance starts up.

Recovery from an Instance Crash

Upon the next instance startup that takes place after SHUTDOWN ABORT or a DBMS crash, the Oracle DBMS detects that the stop SCN for datafiles is not set in the control file during startup. Oracle then performs crash recovery. During crash recovery, Oracle applies redo log records from the online redo logs in a process referred to as roll forward to ensure that all transactions committed before the crash are applied to the datafiles. Following roll forward, active transactions that did not commit are identified from the rollback segments and are undone before the blocks involved in the active transactions can be accessed. This process is referred to as roll back. In our example, the following transaction was active but not committed at the time of the SHUTDOWN ABORT, so it needs to be rolled back:

SQL> insert into x values(100);

After instance startup, the X table exists, but remains empty. Instance recovery happens automatically at database startup without database administrator (DBA) intervention. It may take a while because of the need to apply large amounts of outstanding redo changes to data blocks for transactions that completed and those that didn抰 complete and require roll back.

Recovery from a Media Failure

Up until this point, the checkpoint start SCN in the datafile header has always matched the datafile checkpoint SCN number held in the control file. This is reasonable because during a checkpoint, the datafile checkpoint SCN in the control file and the start SCN in the datafile header are both updated, along with the system checkpoint SCN. The following SQL shows the start SCN from the datafile header and datafile checkpoint SCN from the control file for the same file:

SQL> select ‘controlfile’ “SCN location”,name,checkpoint_change# from v$datafile where name like ‘%users01%’
union
select ‘file header’,name,checkpoint_change# from v$datafile_header where name like ‘%users01%’;

SCN location   NAME                                  CHECKPOINT_CHANGE#
————– ———————————– ——————–
controlfile    /u02/oradata/OMFD1/users01.dbf                  293188
file header    /u02/oradata/OMFD1/users01.dbf                  293188

Unlike the v$datafile view, there is no stop SCN column in the v$datafile_header view because v$datafile_header is not used at instance startup time to indicate that an instance crash occurred. However, the v$datafile_header does provide the Oracle DBMS with the information it requires to perform media recovery. At instance startup, the datafile checkpoint SCN in the control file and the start SCN in the datafile header are checked for equality. If they don抰 match, it is a signal that media recovery is
required.

For example, media recovery is required if a media failure has occurred and the original datafile has been replaced with a backup copy. In this case, the start SCN in the backup copy is less than the checkpoint SCN value in the control file, and Oracle requests archived redo logs generated at the time of previous log switches in order to reapply the changes required to bring the datafile up to the current point in time.

In order to recover the database from a media failure, you must run the database in ARCHIVELOG mode to ensure that all database changes from the online redo logs are stored permanently in archived redo log files. In order to enable ARCHIVELOG mode, you must run the command ALTERDATABASE ARCHIVELOG when the database is in a mounted state.

You can identify files that need recovery after you have replaced a datafile with an older version by starting the instance in mount mode and running the following SQL:

SQL> select file#,change# from v$recover_file;

FILE#    CHANGE#
———- ———-
4     313401

In this example, file 4 is the datafile in the USERS tablespace. By reexecuting the previous SQL to display the datafile checkpoint SCN in the control file and the start SCN in the datafile header, you can see that the start SCN is older due to the restore of the backup datafile that has taken place:

SQL> select ‘controlfile’ “SCN location”,name,checkpoint_change#
from v$datafile where name like ‘%users01%’
union
select ‘file header’,name,checkpoint_change#
from v$datafile_header where name like ‘%users01%’;

SCN location   NAME                                  CHECKPOINT_CHANGE#
————– ———————————– ——————–
controlfile    /u02/oradata/OMFD1/users01.dbf                  313551
file header    /u02/oradata/OMFD1/users01.dbf                  313401
If you were to attempt to open the database, you would receive errors like the following:
ORA-01113: file 4 needs media recovery
ORA-01110: datafile 4: ‘/u02/oradata/OMFD1/users01.dbf’
You can recover the database by issuing RECOVER DATABASE from SQL*Plus while the database is in a mounted state. If the changes needed to recover the database to the point in time before the crash are in an archived redo log, then you will be prompted to accept the suggested name:
ORA-00279: change 313401 generated at 11/10/2001 18:50:23 needed for thread
ORA-00289: suggestion : /u02/oradata/OMFD1/arch/T0001S0000000072.ARC
ORA-00280: change 313401 for thread 1 is in sequence #72

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

If you respond to the prompt using AUTO, Oracle applies any archived redo logs it needs, followed by any necessary changes in the online redo logs, to bring the database right up to the last committed transaction before the media failure that caused the requirement for the restore.

So far, we’ve considered recovery scenarios where the goal is to recover the database to the most recent transaction. This is known as complete recovery. The RECOVER DATABASE command has several other options that enable you to recover from a backup to a point in time before the most recent transaction by rolling forward and then stopping the application of the redo log changes at a specified point. This is known as incomplete recovery. You can specify a time or an SCN as the recovery point. For example,

recover database until time ‘2001-11-10:18:52:00′;
recover database until change 313459;

Before you perform incomplete recovery, it has recommended that you restore a complete database backup first. After incomplete recovery, you must open the mounted database with ALTER DATABASE OPEN RESETLOGS. This creates a new incarnation of the database and clears the contents of the existing redo logs to make sure they can’t be applied.

Recovery from a Media Failure Using a Backup Control File

In the previous example, we had access to a current control file at the time of the media failure. This means that none of the start SCN values in the datafile headers exceeded the system checkpoint SCN number in the control file. To recap, the system checkpoint number is given by the following:

SQL> select checkpoint_change# from v$database;

You might be wondering why Oracle needs to maintain the last system checkpoint value in the control file as well as checkpoint SCNs in the control file for each datafile (as used in the previous example). There are two reasons for this. The first is that you might have read-only tablespaces in your database. In this case, the database checkpoint SCN increases, and the checkpoint SCN for the datafiles in the read-only tablespace remains frozen in the control file.

The following SQL report output shows a database with a read-write tablespace (USERS) and read-only tablespace (TEST). The start SCN in the file header and the checkpoint SCN in the control file for TEST are less than the system checkpoint value. Once a tablespace is read only, checkpoints have no effect on the files in it. The other read-write tablespace has checkpoint values that match the system checkpoint:

SCN location         NAME                             CHECKPOINT_CHANGE#
——————– ———————————- —————-
controlfile          SYSTEM checkpoint                           355390
file header          /u02/oradata/OD2/users01.dbf                355390
file in controlfile  /u02/oradata/OD2/users01.dbf                355390
file header          /u02/oradata/OD2/test01.dbf                 355383
file in controlfile  /u02/oradata/OD2/test01.dbf                 355383

The second reason for the maintenance of multiple checkpoint SCNs in the control file is that you might not have a current control file available at recovery time. In this case, you need to restore an earlier control file before you can perform a recovery. The system checkpoint in the control file may indicate an earlier change than the start SCN in the datafile headers.

The following SQL shows an example where the system checkpoint SCN and datafile checkpoint SCN indicate an earlier change than the start SCN in the datafile header:

SQL> select ‘controlfile’ “SCN location”,’SYSTEM checkpoint’ name,checkpoint_change#
from v$database
union
select ‘file in controlfile’,name,checkpoint_change#
from v$datafile where name like ‘users01%’
union
select ‘file header’,name,checkpoint_change#
from v$datafile_header where name like ‘%users01%’;

SCN location        NAME                                            CHECKPOINT_CHANGE#
——————- ——————————   ——————
controlfile         SYSTEM checkpoint                                       333765
file header         /u02/oradata/OD2/users01.dbf                  355253
file in controlfile /u02/oradata/OD2/users01.dbf                 333765

If try you to recover a database in the usual way in this situation, Oracle detects that the control file is older than some of the datafiles, as indicated by the checkpoint SCN values in the datafile headers, and reports the following message:

SQL> recover database
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

If you want to proceed with recovery in this situation, you need to indicate to Oracle that a noncurrent control file possibly containing mismatches in the SCN values identified by the previous error messages is about to be specified for recovery by using the following command:
recover database using BACKUP CONTROLFILE;

该发烧会反复，吃什么药都不管用，发烧3天后，温度会自动降低到正常，并且身上会起一些小的红色的疹子；出了疹子之后发烧就会好，疹子也会在1到天后自动消失。这是宝宝增强自身抵抗力的过程。但如果宝宝连续发烧超过3天，则要留意医院就诊最好。

特此提醒广大新生儿家长，宝宝第一次发烧的时候要淡定。

Redis是一款开源nosql key-value数据库产品；，使用redis的开发人员很多，它的value可以是几种数据结如数组，链表，因此也常被使用者称为数据结构key-value数据库。其作者和社区都很活跃，得益于其短小精悍，容易上手，发展迅猛，而且国内也有不少标杆用户，如weibo和taobao等。

btw:NoSQLFan是个好网站，至于你信不信，我反正信了

Plus LAST_CALL_ET,it’s easier to identify session status and detect problem SQL.

SQL>   select sid,serial#,LAST_CALL_ET,sql_hash_value,status,(SYSDATE-SQL_EXEC_START)*86400  from v$session where status=’ACTIVE’ and SQL_EXEC_START is not null order by (SYSDATE-SQL_EXEC_START)*86400 desc;

SID    SERIAL# LAST_CALL_ET SQL_HASH_VALUE STATUS   RUN_SECONDS
———- ———- ———— ————– ——– ———–
15022      43583            1      404603867 ACTIVE            31
15404      28683           27     3096975108 ACTIVE            26
28569       3837           26     3096975108 ACTIVE            26
28834      28447           26     3096975108 ACTIVE            26
28440      57479           26     3096975108 ACTIVE            26
28487      43835           26     3096975108 ACTIVE            26
28477       1469           26     3096975108 ACTIVE            26
28448      44175           26     3096975108 ACTIVE            26
17793      49565            9     3770652317 ACTIVE             9
28602      12903            7     1278135340 ACTIVE             7
25851         25              5     4149984594 ACTIVE             5

Way 1:

sql> alter database stop logical standby apply ;
sql> exec dbms_logstdby.instantiate_table(‘SCOTT’,’EMP’,’DBLINK’);
sql> alter database start logical standby apply immediate;

The above command also does expdp/impdp using the network_link which is the db link.But it will drop the existing out-of-sync table first, then creates and loads it with the data the source using the db link.

Way 2:

manually expdp & impdp out-of-sync tables from master to logical standby.

sql> alter database stop logical standby apply;
sql> exec dbms_logstdby.skip (stmnt =>'DML',schema_name =>'SCOTT',table_name =>'EMP');
sql> drop table scott.emp
sql> create table scott.emp (ename varchar(2),........);
sql>SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS;

APPLIED_SCN :-All the transactions with COMMIT SCN lower than or equal to this SCN have been applied.

then on Primary, do flashback expdp with SCN=APPLIED_SCN.

expdp system/xxxx tables=scott.emp dumpfile=expemp.dmp flashback_scn=<APPLIED_SCN>
impdp system/xxxx dumpfile=expemp.dmp tables=scott.emp table_exists_actions=append

you can expdp rows only, then create index manually with large sort_area_size and parallel.

Everything is done so far. Start apply.

sql> exec dbms_logstdby.unskip(stmnt =>’DML’,schema_name =>’SCOTT’,table_name =>’EMP’);
sql> alter database start logical standby apply;

Resmgr means it’s related to oracle resource manager, but if you’ve disabled it in past, why does it come from?

You should “ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:' ” to deeply disable it or use underscore parameter _resource_manager_always_on = false.

Resource Manager Plan Changes Settings Every Week [ID 759503.1]
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.1 - Release: 10.2 to 11.2
Information in this document applies to any platform.
Goal
Detailed description with Example
———————————-
1) Noticed that the resource manager plan was set to

"resource_manager_plan string SCHEDULER[0x22BB]:SYSTEM_PLAN".

2) Changed this using the command

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '' SCOPE=BOTH;

3) Every week when checking on this database setting it goes back to the setting

"SCHEDULER[0x22BB]:SYSTEM_PLAN".

I keep having to issue the following command, but the resource manager plan keeps changing back

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '' SCOPE=BOTH;

The database is not being recycled so why is the setting changing. It is causing performance issues every time it changes back.
What could cause this setting to change back?

Solution

It is possible that the scheduler windows are altering the resource plan. A scheduler window can have a resource plan associated with it. The default plan associated with default weekend and weeknight windows is the system_plan.

You can see that by looking at the following view:

select * from V$RSRC_PLAN_HISTORY order by SEQUENCE#;

To set the resource plan such that the scheduler cannot alter the plan, do the following:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:Desired_Resource_Plan' scope=both;

OR

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'FORCE:' scope=both; --> For Null

OR

Change the active windows to use the null resource manager plan (or other unrestrictive plan) using:

execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
--And
execute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');

(execute the same for any other scheduler windows that exist, changing the window name).

From there on, the scheduler windows will not be able to change the resource plan.

The active resource plan can be shown by:

select * from v$rsrc_plan;

骆驼买３个，数据存３份，孩子养３个。

redis-tutorial上看到的。

Last year, Nat and I went to the Royal Geographical Society’s Explore conference. One of the sessions was about surviving in the desert with camels, and the point was made that you should always take three camels in to the desert with you. That way, if one of them breaks its leg and another one runs off you can still make it out safely.

When the Guardian hosted UK ScaleCamp a few months later, the same principle came up again - this time referring to data. If your data is on one machine (or in just one data centre), you have a high risk of losing it no matter how well specced that individual machine is. If it’s being served from two machines you’re still at risk - if one of them dies, the other one is dramatically more likely to die shortly afterwards since it now has to handle twice the load.

(Photo by Michael and Donna)

Tom的演讲内容中，留意到以下几点。

1. Hybrid Columnar Compression:结合exdata,zfs等号称可以压缩50倍。!T的数据压缩为20G就是。
2. Oracle Resource Manager可以管理应用程序和实例占用多少CPU,IO等资源。可以作为虚拟化和云的一种控制手段或者补充。
3. Oracle的 bigdata 从头到尾从里到外的解决方案
4. cloud.oracle.com
5. Oracle的发展方向:软硬结合，卖软件卖服务卖硬件卖云没有不卖的。

回来后查了一下Hybrid Columnar Compression，在Oracle EBS上倒是有52倍的压缩比。通常OLTP Compress能实现4倍左右的压缩比，个人感觉已经很强大了。

一些介绍Oracle compression的文档：

• Hybrid Columnar Compression (HCC) on Exadata －－ Oracle white paper
• Exadata Hybrid Columnar Compression: The Next-Generation Compression Technology
• Hybrid Columnar Compression in Oracle Exadata v2 — Mark
• Oracle Advanced Compression in Database 11g Rel. 2: Value/Performance –oracle 2010 open world
• Oracle Announces Hybrid Columnar Compression Support for ZFS Storage Appliances and Pillar Axiom Storage Systems – September 30, 2011

使用该参数需要注意参数INBOUND_CONNECT_TIMEOUT的设置，以避免发生过多的“ORA-12170: TNS:Connect timeout occurred”错误.

Connection Rate Limiter Parameters

The connection rate limiter feature in the Oracle Net Listener enables a DBA to limit the number of new connections handled by the listener. When this feature is enabled, Oracle Net Listener imposes a user-specified maximum limit on the number of new connections handled by the listener every second.

Depending on the configuration, the rate can be applied to a collection of endpoints, or to a specific endpoint.

This feature is controlled through the following two listener.ora configuration parameters:

• CONNECTION_RATE_listener name

• RATE_LIMIT

CONNECTION_RATE_listener name

Purpose

To specify a global rate that is enforced across all listening endpoints that are rate-limited. When this parameter is specified, it overrides any endpoint-level numeric rate values that might be specified.

Syntax

CONNECTION_RATE_listener_name=number_of_connections_per_second

RATE_LIMIT

Purpose

To indicate that a particular listening endpoint is rate limited. The parameter is specified in the ADDRESS section of the listener endpoint configuration.

Syntax

LISTENER= (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))
)

• When the RATE_LIMIT parameter is set to yes, the end-point is included in the enforcement of a listener-wide connection rate. This is used with the CONNECTION_RATE_listener_name parameter.
• When the RATE_LIMIT parameter is set to a value greater than 0, the rate limit is enforced at that endpoint level.

Examples

The following examples use the CONNECTION_RATE_listener name and RATE_LIMIT parameters.

Example 1

CONNECTION_RATE_LISTENER=10
LISTENER=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523))
)

In the preceding example, the total number of new connections through ports 1521 and 1522 is limited at 10 every second. Connections through port 1523 are not limited and do not count towards the overall rate of 10 connections every second.

Example 2

LISTENER= (ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=5))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=10))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523))
)

In the preceding example, the connection rates are enforced at the endpoint level. A maximum of 5 connections are processed through port 1521 every second. The limit for connections through port 1522 is 10 every second. Connections through port 1523 are not limited.

我在11gr2中测试，如上example 1的设置reload listener后能够起作用；example 2的设置reload & restart listener后不起作用。