天天看点

[20160119]日志频繁切换.txt

[20160119]日志频繁切换.txt

--元旦后的事情,主要问题是节前给主库增加几个数据文件,本来dg的磁盘空间就很紧张,加上节假日没人检查dg。

--导致dg磁盘空间满,出现了日志频繁切换,做1个记录:

1.环境:

SYS@xxxxdg2> @ &r/ver1

PORT_STRING                    VERSION        BANNER

------------------------------ -------------- --------------------------------------------------------------------------------

x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SELECT   TRUNC (first_time) "Date", TO_CHAR (first_time, 'Dy') "Day", COUNT (1) "Total",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '00', 1, 0)) h0,

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '01', 1, 0)) "h1",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '02', 1, 0)) "h2",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '03', 1, 0)) "h3",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '04', 1, 0)) "h4",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '05', 1, 0)) "h5",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '06', 1, 0)) "h6",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '07', 1, 0)) "h7",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '08', 1, 0)) "h8",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '09', 1, 0)) "h9",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '10', 1, 0)) "h10",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '11', 1, 0)) "h11",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '12', 1, 0)) "h12",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '13', 1, 0)) "h13",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '14', 1, 0)) "h14",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '15', 1, 0)) "h15",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '16', 1, 0)) "h16",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '17', 1, 0)) "h17",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '18', 1, 0)) "h18",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '19', 1, 0)) "h19",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '20', 1, 0)) "h20",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '21', 1, 0)) "h21",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '22', 1, 0)) "h22",

         SUM (DECODE (TO_CHAR (first_time, 'hh24'), '23', 1, 0)) "h23", ROUND (COUNT (1) / 24, 2) "Avg"

    FROM gv$log_history

   WHERE first_time >= trunc(SYSDATE) - 20

   and thread# = inst_id

GROUP BY TRUNC (first_time), TO_CHAR (first_time, 'Dy')

ORDER BY 1 DESC;

Date                Day         Total   H0   h1   h2   h3   h4   h5   h6   h7   h8   h9  h10  h11  h12  h13  h14  h15  h16  h17  h18  h19  h20  h21  h22  h23     Avg

------------------- ------ ---------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- -------

...

2016-01-03 00:00:00 Sun             4    0    0    0    0    0    4    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0     .17

2016-01-02 00:00:00 Sat            98    0    0    0    0    0    9   12   12   13   12   11   12    8    2    6    1    0    0    0    0    0    0    0    0    4.08

2016-01-01 00:00:00 Fri             4    0    0    0    0    0    4    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0     .17

SELECT round((next_time - first_time) * 86400,2) xx, sequence#,first_time,next_time,blocks,creator,completion_time

    FROM V$ARCHIVED_LOG a

   WHERE     first_time BETWEEN '2016/01/02' AND '2016/01/03'

         AND name LIKE '+RECOC1%'

         AND thread# = 1

ORDER BY first_time ;

        XX  SEQUENCE# FIRST_TIME          NEXT_TIME               BLOCKS CREATOR COMPLETION_TIME

---------- ---------- ------------------- ------------------- ---------- ------- -------------------

        24       1812 2016-01-02 05:27:03 2016-01-02 05:27:27         45 ARCH    2016-01-02 05:27:27

       390       1813 2016-01-02 05:27:27 2016-01-02 05:33:57       1696 ARCH    2016-01-02 05:33:57

       660       1814 2016-01-02 05:33:57 2016-01-02 05:44:57       5086 ARCH    2016-01-02 05:44:57

       360       1815 2016-01-02 05:44:57 2016-01-02 05:50:57       3199 ARCH    2016-01-02 05:50:58

       961       1816 2016-01-02 05:50:57 2016-01-02 06:06:58      12949 ARCH    2016-01-02 06:06:58

       600       1817 2016-01-02 06:06:58 2016-01-02 06:16:58       6508 ARCH    2016-01-02 06:16:58

       660       1818 2016-01-02 06:16:58 2016-01-02 06:27:58       5870 ARCH    2016-01-02 06:27:58

       361       1819 2016-01-02 06:27:58 2016-01-02 06:33:59       3229 ARCH    2016-01-02 06:33:59

       660       1820 2016-01-02 06:33:59 2016-01-02 06:44:59       3228 ARCH    2016-01-02 06:44:59

       600       1821 2016-01-02 06:44:59 2016-01-02 06:54:59       9595 ARCH    2016-01-02 06:54:59

       600       1822 2016-01-02 06:54:59 2016-01-02 07:04:59      17983 ARCH    2016-01-02 07:05:00

       361       1823 2016-01-02 07:04:59 2016-01-02 07:11:00       7856 ARCH    2016-01-02 07:11:00

       360       1824 2016-01-02 07:11:00 2016-01-02 07:17:00      11690 ARCH    2016-01-02 07:17:00

       603       1825 2016-01-02 07:17:00 2016-01-02 07:27:03      19300 ARCH    2016-01-02 07:27:03

       657       1826 2016-01-02 07:27:03 2016-01-02 07:38:00      21525 ARCH    2016-01-02 07:38:01

       601       1827 2016-01-02 07:38:00 2016-01-02 07:48:01      17937 ARCH    2016-01-02 07:48:01

       363       1828 2016-01-02 07:48:01 2016-01-02 07:54:04      19807 ARCH    2016-01-02 07:54:04

       360       1829 2016-01-02 07:54:04 2016-01-02 08:00:04      19327 ARCH    2016-01-02 08:00:04

       600       1830 2016-01-02 08:00:04 2016-01-02 08:10:04      55352 ARCH    2016-01-02 08:10:05

       661       1831 2016-01-02 08:10:04 2016-01-02 08:21:05      62631 ARCH    2016-01-02 08:21:05

       600       1832 2016-01-02 08:21:05 2016-01-02 08:31:05      65873 ARCH    2016-01-02 08:31:05

       360       1833 2016-01-02 08:31:05 2016-01-02 08:37:05      44382 ARCH    2016-01-02 08:37:05

       357       1834 2016-01-02 08:37:05 2016-01-02 08:43:02      43982 ARCH    2016-01-02 08:43:03

       604       1835 2016-01-02 08:43:02 2016-01-02 08:53:06      89033 ARCH    2016-01-02 08:53:06

       660       1836 2016-01-02 08:53:06 2016-01-02 09:04:06     104306 ARCH    2016-01-02 09:04:07

       600       1837 2016-01-02 09:04:06 2016-01-02 09:14:06     101150 ARCH    2016-01-02 09:14:07

       661       1838 2016-01-02 09:14:06 2016-01-02 09:25:07     113452 ARCH    2016-01-02 09:25:07

       600       1839 2016-01-02 09:25:07 2016-01-02 09:35:07      99097 ARCH    2016-01-02 09:35:07

       600       1840 2016-01-02 09:35:07 2016-01-02 09:45:07     107339 ARCH    2016-01-02 09:45:08

       661       1841 2016-01-02 09:45:07 2016-01-02 09:56:08     118777 ARCH    2016-01-02 09:56:08

       600       1842 2016-01-02 09:56:08 2016-01-02 10:06:08     107504 ARCH    2016-01-02 10:06:08

       600       1843 2016-01-02 10:06:08 2016-01-02 10:16:08     132672 ARCH    2016-01-02 10:16:09

       601       1844 2016-01-02 10:16:08 2016-01-02 10:26:09     115642 ARCH    2016-01-02 10:26:09

       600       1845 2016-01-02 10:26:09 2016-01-02 10:36:09     107361 ARCH    2016-01-02 10:36:09

       600       1846 2016-01-02 10:36:09 2016-01-02 10:46:09     111693 ARCH    2016-01-02 10:46:09

       660       1847 2016-01-02 10:46:09 2016-01-02 10:57:09      92669 ARCH    2016-01-02 10:57:10

       601       1848 2016-01-02 10:57:09 2016-01-02 11:07:10      99623 ARCH    2016-01-02 11:07:10

       600       1849 2016-01-02 11:07:10 2016-01-02 11:17:10      98332 ARCH    2016-01-02 11:17:10

       600       1850 2016-01-02 11:17:10 2016-01-02 11:27:10      98874 ARCH    2016-01-02 11:27:11

       601       1851 2016-01-02 11:27:10 2016-01-02 11:37:11      88746 ARCH    2016-01-02 11:37:11

       600       1852 2016-01-02 11:37:11 2016-01-02 11:47:11      73500 ARCH    2016-01-02 11:47:11

       600       1853 2016-01-02 11:47:11 2016-01-02 11:57:11      76376 ARCH    2016-01-02 11:57:12

       661       1854 2016-01-02 11:57:11 2016-01-02 12:08:12      56820 ARCH    2016-01-02 12:08:12

      1800       1855 2016-01-02 12:08:12 2016-01-02 12:38:12      87001 ARCH    2016-01-02 12:38:13

       601       1856 2016-01-02 12:38:12 2016-01-02 12:48:13      25307 ARCH    2016-01-02 12:48:13

       600       1857 2016-01-02 12:48:13 2016-01-02 12:58:13      20046 ARCH    2016-01-02 12:58:13

       901       1858 2016-01-02 12:58:13 2016-01-02 13:13:14      45822 ARCH    2016-01-02 13:13:14

      3601       1859 2016-01-02 13:13:14 2016-01-02 14:13:15     151869 ARCH    2016-01-02 14:13:16

      1201       1860 2016-01-02 14:13:15 2016-01-02 14:33:16      62884 ARCH    2016-01-02 14:33:16

      1140       1861 2016-01-02 14:33:16 2016-01-02 14:52:16     168460 ARCH    2016-01-02 14:52:17

       361       1862 2016-01-02 14:52:16 2016-01-02 14:58:17      43611 ARCH    2016-01-02 14:58:17

       360       1863 2016-01-02 14:58:17 2016-01-02 15:04:17      33833 ARCH    2016-01-02 15:04:17

     51769       1864 2016-01-02 15:04:17 2016-01-03 05:27:06    2617582 ARCH    2016-01-03 05:27:19

--sum(blocks)总量与平时的放假的业务基本相当。多数600秒,当然也有部分360秒切换1次。另外奇怪的是到了15:04:17时间后频繁切换日志的情况消失。

--我检查dg的alert*.log文件,发现存在如下信息,到了2016/01/02 15:07:35 2016 ,alert*.log出现:

Sat Jan 02 15:07:35 2016

Non critical error ORA-48181 caught while writing to trace file "/u01/app/oracle/diag/rdbms/dbcndg2/dbcndg2/trace/dbcndg2_m000_26694.trc"

Error message: Linux-x86_64 Error: 28: No space left on device

Additional information: 1

Writing to the above trace file is disabled for now on...

Sat Jan 02 15:08:35 2016

--到了15:07:35 2016,已经没有空间了。节后检查dg发现磁盘满,当时并没有注意日志的切换问题,整理出磁盘空间后一切ok。

总结自己遇到日志频繁切换的主要因素:

1.CP数量U太多,要设置每个redo大一些,最好1G以上。

2.archive_lag_target参数

3.dg磁盘空间满,也会出现这种情况。

4.网络传输速度慢,这个要进一步测试,在log_archive_dest_N包含SYNC的情况下,有时会出现频繁切换的情况,这个好像在网络从坏到

  好的情况时,会出现切换情况,我还要需要一些测试。