oracle sequnece 介绍以及 监控
###sequnece 介绍
http://www.dba-oracle.com/t_rac_tuning_sequence_order_parameter.htm
order by 可能会影响性能，但是对确认时间戳 比较重要
order子句保证序列的下一个值是行中的下一个值，不管接收请求的实例是什么。
为了举例说明，假设一个序列定义为cache=20。实例1的缓存中有序列值1到20。实例2的缓存中有序列值21到40。
通常，并发会话可能按以下顺序生成序列值：1、2、21、3、22、4、23和24。在本例中，可以很容易地确定在哪个实例中生成了哪些值。
每个序列值都大于该实例中它前面的值。但是，当按时间顺序检查时，这些值不是按顺序排列的。
如果序列的目的是生成唯一的值，就像通常对合成主键所做的那样，那么当随着时间的推移查看这些值时，这些值跳来跳去的事实就不那么重要了。
然而，有些应用需要序列来表示时间顺序，即序列值为11的序列值发生在序列值为12的记录之前的某个时间。在这些情况下，
oracle rac应用程序必须使用order子句来保证序列的值是按顺序生成的，无论下一个值是哪个实例生成的。
下面是这样一个序列的例子。
Sequence order parameter
Worse than not caching values of a sequence in Oracle RAC is using the order clause when creating a sequence database object. For the discussion in this section, the example sequence is dropped and recreated with the order clause.
SQL> drop sequence
2 cache_example_sequence;
Sequence dropped.
SQL> create sequence
2 cache_example_sequence
3 start with 1
4 increment by 1
5 order;
Sequence created.
Many people have never seen the order clause when used in conjunction with a sequence database object. The reason why this clause is rarely used is because the clause only has relevance for Oracle RAC databases, and even then, it is normally a bad idea to use the clause, as will be shown in this section.
The order clause guarantees that the sequence's next value is the next one in line, no matter the instance that received the request. To illustrate, assume a sequence defined with cache=20. Instance 1 has sequence values 1 through 20 in its cache. Instance 2 has sequence values 21 through 40 in its cache. Normally, concurrent sessions might generate sequence values in this order: 1, 2, 21, 3, 22, 4, 23, and 24. It can easily be determined which values were generated in which instance in this example. Each sequence value is larger than the one that preceded it only in that instance. However, when examined chronologically, the values are not in order.
If the purpose of the sequence is to generate unique values, as is often done for synthetic primary keys, the fact that the values jump around when viewed over time is of little concern. Yet some applications need the sequences to denote time ordering, i.e. a sequence value of 11 occurred some time prior to the record with the sequence value of 12. In those cases, Oracle RAC applications must use the order clause to guarantee the sequence's values are generated in order, no matter which instance the next value was generated. An example of such a sequence is seen next.
SQL> create sequence
2 example_order_seq
3 start with 1
4 increment by 1
5 cache 20
6 order;
Sequence created.
Notice in the example above that the sequence is defined with cache=20 and order. Now let's look at sessions in two instances generating some next set of values from this sequence.
SQL> select
2 instance_name,
3 example_order_seq.nextval
4 from
5 v$instance;
INSTANCE_NAME NEXTVAL
---------------- ----------
orcl1 1
SQL> select
2 instance_name,
3 example_order_seq.nextval
4 from
5 v$instance;
INSTANCE_NAME NEXTVAL
---------------- ----------
orcl2 2
SQL> select
2 instance_name,
3 example_order_seq.nextval
4 from
5 v$instance;
INSTANCE_NAME NEXTVAL
---------------- ----------
orcl1 3
SQL> select
2 instance_name,
3 example_order_seq.nextval
4 from
5 v$instance;
INSTANCE_NAME NEXTVAL
---------------- ----------
orcl2 4
Even though the sequence was denoted to cache sequence values and those values were selected from one instance, then the next and so on, the order clause ensured each subsequent value would be in numerical order. The order clause effectively makes the sequence have a nocache setting.
Similar to examining the performance of a sequence in the previous section, the performance of the sequence using the order clause can be easily determined. To do this, the sequence is dropped and then recreated.
SQL> drop sequence
2 cache_example_sequence;
Sequence dropped.
SQL> create sequence
2 cache_example_sequence
3 start with 1
4 increment by 1
5 nocache
6 order;
Sequence created.
Now that the sequence has been created, the same PL/SQL block as before is executed in two sessions connected to the two instances of the RAC cluster.
SQL> set timing on
SQL> declare
2 curr_val number;
3 cnt number;
4 begin
5 cnt := 0;
6 while cnt <= 100000
7 loop
8 select cache_example_sequence.nextval
9 into curr_val
10 from
11 dual;
12 cnt := cnt + 1;
13 end loop;
14 end;
15 /
PL/SQL procedure successfully completed.
Elapsed: 00:18:54.95
The PL/SQL block took about 19 minutes to complete in the first instance. The same block took almost the same identical time to complete in the second instance. These results are similar to the nocache example seen previously. The tests will be repeated for cache values of 20, 100, and 1000 as was previously performed. The following table shows the cache values and the effect with the order clause compared to the earlier tests without explicit ordering of the sequence values.
|
|
NOORDER |
ORDER |
||
|
Cache Value |
Node 1 |
Node 2 |
Node 1 |
Node 2 |
|
None |
19:59.61 |
20:43.22 |
18:54.95 |
18:55.34 |
|
20 |
00:41.19 |
00:49.18 |
01:17.34 |
01:19.75 |
|
100 |
00:10.98 |
00:11.57 |
00:33.41 |
00:32.45 |
|
1000 |
00:01.06 |
00:02.62 |
00:29.30 |
00:28.74 |
Table 3.2 Sequence Runtimes With Caching and ORDER
From the results in the table above, it is easy to see that with no caching of sequence values, the order clause had slightly better results. As the cache value increased slightly, requiring a specific order to the sequence values started to have a negative effect. Instead of running in less than fifty seconds, the order clause made the sequence run in less than eighty seconds. When the cache value was set to 100, the ordered sequence performed three times worse than with no order. Most significantly was when the caching was increased to 1000, great improvement occurred with noorder, but no improvement with order.
Next, let's examine the top wait events for one of these sessions.
SQL> @current_session_top5_waits.sql
EVENT TOTAL_WAITS TIME_WAITED
------------------------------ ----------- -----------
gc cr block 2-way 66167 7710
gc cr block busy 31606 5130
gc cr block lost 1 28
db file sequential read 12 1
Disk file operations I/O 3 0
Surprisingly, the row cache lock wait event is not seen here. Instead, the top wait events are Cache Fusion related.
The Data Dictionary can be queried to easily find those sequences that are defined to order the values.
select
sequence_owner,
sequence_name
from
dba_sequences
where
order_flag='Y'
order by
sequence_owner,
sequence_name;
The query above will return a number of sequences owned by SYS and SYSTEM. With one exception that will be discussed in the next section, the database administrator should not modify the sequences that are part of the Data Dictionary.
For those sequences returned from the above query that belong to application owners, the database administrator needs to determine if the ordering of sequence values is truly necessary. If the order clause is not a business requirement, it should be removed.
In this section, a simple example showed how using the order clause quickly negates any benefits of caching sequence values. This should be no surprise as the clause serializes access to the sequence's next values across all instances. As such, the orderclause should only be used for those sequences that have specific business requirements stating that the sequence's values are to denote a time ordering. The absence of such a requirement would negate the need for the order clause. It is a good practice to use the order clause sparingly and only when completely necessary.
###sample 监控
需要监控数据库的序列，在达到最大值前，进行告警。特别是mysql，往往因为字段的定义和auto incremental的定义不同，导致各自的上限不同。
https://oracleblog.org/working-case/monitor-sequence/
Oracle：
|
1
2
3
4
5
6
7
8
9
10
11
|
SELECT
x.*,
CASE WHEN increment_by<0
THEN round(last_number/min_value*100,4)
WHEN increment_by>0
THEN round(last_number/max_value*100,4)
ELSE 0
END
AS percent_usage
from DBA_SEQUENCES x WHERE cycle_flag='N'
ORDER BY percent_usage DESC;
|
