打补丁时在main import这个部分极慢，运行了24小时都木有动静，肿摸办？

sydongsun

如果查看日志，没有明显看出有问题的话.
几乎静止，这表示系统已经没有在做import。检查kernel或者数据库是否要更新。

你最好按照官方的安装文档的步骤，检查是否有某些地方你没有遵照执行。也检查你的软件版本到support网站查询别人是否有类似的错误。

woshiyiziyu

以前碰到过打一天都没有结束的，后来更新了数据库的统计值重新再打就过去了。
来自大榕树QQ群

w39

woshiyiziyu 发表于 2013-11-29 14:59
以前碰到过打一天都没有结束的，后来更新了数据库的统计值重新再打就过去了。
来自大榕树QQ群

怎么更新？

woshiyiziyu

solution manager 7.01在打支持包SAPKU50014（Support Package 14 for SAP CRM 5.0）的时候发现特别的慢，等了1个星期还没有结束。
在sm50中发现进程一直在用程序SAPMS38L删除D010INC表，然后用关键字D010INC在sap网站中查找，找到一个note Note 1232776 - Long runtimes for accesses to D010INC or D010TAB
然后我就登陆系统查看D010INC的上一次的统计时间是2010年12月16日，而现在的时间是2011-1-27。但是在QAS系统中D010INC的上一次的统计时间是2008年1月10号，所以看起来和统计时间没有关系。
SLM
SQL>set timing on
SQL> SELECT TO_CHAR(LAST_ANALYZED, 'DD.MM.YYYY, HH24:MI:SS') FROM
  2  DBA_TABLES WHERE
  3  owner='SAPSR3' and TABLE_NAME ='D010INC';

TO_CHAR(LAST_ANALYZE
--------------------
16.12.2010, 04:44:18

Elapsed: 00:00:00.07

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

QAS
SQL>set timing on
SQL> SELECT TO_CHAR(LAST_ANALYZED, 'DD.MM.YYYY, HH24:MI:SS') FROM
  2  DBA_TABLES WHERE
  3  owner='SAPSR3' and TABLE_NAME ='D010INC';

TO_CHAR(LAST_ANALYZE
--------------------
01.10.2008, 08:52:24

Elapsed: 00:00:00.00

然后我执行了一条语句select count(*) from SAPSR3.D010INC;发现用了16分钟才执行完毕。而在QAS系统中只要55秒。

SLM
SQL> set autotrace on
SQL> select count(*) from SAPSR3.D010INC;

  COUNT(*)
----------
  14169040

Elapsed: 00:16:06.59

Execution Plan
----------------------------------------------------------
Plan hash value: 3633007648

----------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |     1 |     0   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |           |     1 |            |          |
|   2 |   INDEX FULL SCAN| D010INC~0 |     1 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     236536  consistent gets
     235954  physical reads
          0  redo size
        518  bytes sent via SQL*Net to client
        487  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
-----------------------------------------------------------------------------------------------------------------------------

QAS
SQL> set autotrace on;
SQL> set timing on;
SQL> select count(*) from SAPSR3.D010INC;

  COUNT(*)
----------
  16167676

Elapsed: 00:00:55.49

Execution Plan
----------------------------------------------------------
Plan hash value: 861930282

----------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |     1 | 20977   (2)| 00:03:23 |
|   1 |  SORT AGGREGATE    |         |     1 |            |          |
|   2 |   TABLE ACCESS FULL| D010INC |    16M| 20977   (2)| 00:03:23 |
----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          2  recursive calls
          1  db block gets
     131020  consistent gets
     130993  physical reads
        176  redo size
        518  bytes sent via SQL*Net to client
        464  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

我发现在SLM中使用了索引D010INC~0，而在QAS是直接全表扫描，所以我认为是统计值过旧的问题。

然后我接着查看了索引D010INC~0的上次统计值更新时间，发现没有分析过。
SQL> SELECT TO_CHAR(LAST_ANALYZED, 'DD.MM.YYYY, HH24:MI:SS') FROM
  2  DBA_TABLES WHERE
  3  owner='SAPSR3' and TABLE_NAME ='D010INC~0';

no rows selected

Elapsed: 00:00:00.00

我决定重新收集表D010INC的统计信息，根据Note 1020260 - Delivery of Oracle statistics (Oracle 10g, 11g)
在olaslm用户下敲入命令
brconnect -u / -c -f stats -t SAPSR3.D010INC -f collect
erp-backupraslm 14> brconnect -u / -c -f stats -t SAPSR3.D010INC -f collect
BR0801I BRCONNECT 7.00 (40)
BR0805I Start of BRCONNECT processing: cefchsec.sta 2011-01-27 17.07.22
BR0484I BRCONNECT log file: /oracle/SLM/sapcheck/cefchsec.sta

BR0280I BRCONNECT time stamp: 2011-01-27 17.07.26
BR0813I Schema owners found in database SLM: SAPSR3*, SAPSR3DB%

BR0280I BRCONNECT time stamp: 2011-01-27 17.07.29
BR0807I Name of database instance: SLM
BR0808I BRCONNECT action ID: cefchsec
BR0809I BRCONNECT function ID: sta
BR0810I BRCONNECT function: stats
BR0812I Database objects for processing: SAPSR3.D010INC
BR0851I Number of tables with missing statistics: 0
BR0852I Number of tables to delete statistics: 0
BR0854I Number of tables to collect statistics without checking: 1
Owner SAPSR3: 1
D010INC   
BR0855I Number of indexes with missing statistics: 0
BR0856I Number of indexes to delete statistics: 0
BR0857I Number of indexes to collect statistics: 0
BR0853I Number of tables to check (and collect if needed) statistics: 0
BR0862I Force option with value 'collect' set
BR0126I Unattended mode active - no operator confirmation required

BR0280I BRCONNECT time stamp: 2011-01-27 17.07.29
BR0877I Checking and collecting table and index statistics...
BR0280I BRCONNECT time stamp: 2011-01-27 17.07.29
BR0881I Collecting statistics for table SAPSR3.D010INC with method/sample C ...
BR0280I BRCONNECT time stamp: 2011-01-27 18.30.36
BR0884I Statistics collected for table: SAPSR3.D010INC, rows old/new: 0/14169040

BR0280I BRCONNECT time stamp: 2011-01-27 18.30.36
BR0850I 1 of 1 object processed - 0.002 of 0.002 units done
BR0204I Percentage done: 100.00%, estimated end time: 18:30
BR0001I **************************************************

BR0280I BRCONNECT time stamp: 2011-01-27 18.30.37
BR0879I Statistics checked for 0 tables
BR0878I Number of tables selected to collect statistics after check: 0
BR0880I Statistics collected for 1/0 tables/indexes

BR0806I End of BRCONNECT processing: cefchsec.sta 2011-01-27 18.30.37
BR0280I BRCONNECT time stamp: 2011-01-27 18.30.38
BR0802I BRCONNECT completed successfully
发现关键字rows old/new: 0/14169040
再次查看D010INC的统计信息，发现有了变化：列Rows从1变为了14M
SQL>  explain plan for select count(*) from SAPSR3.D010INC;

Explained.

Elapsed: 00:00:00.05
SQL>  select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3904803419

----------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |     1 |     0   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |           |     1 |            |          |
|   2 |   INDEX FULL SCAN| D010INC~1 |    14M|     0   (0)| 00:00:01 |
----------------------------------------------------------------------

9 rows selected.

Elapsed: 00:00:00.01
查看一下上次分析的时间，发现已经更改为2011.1.27
SQL> SELECT TO_CHAR(LAST_ANALYZED, 'DD.MM.YYYY, HH24:MI:SS') FROM
  2  DBA_TABLES WHERE
  3  owner='SAPSR3' and TABLE_NAME ='D010INC';

TO_CHAR(LAST_ANALYZE
--------------------
27.01.2011, 17:24:19

Elapsed: 00:00:00.09

用stms再次查看，发现支持包SAPKU50014已经打好了，甚至
SAPKITL430
SAPKNA7015
SAPK-70103INPIBASIS也打好了

看来是统计值太旧的问题

sydongsun

w39 发表于 2013-11-29 15:04
怎么更新？

在你安装软件版本的install master guide应该有这样的说明的。

w39

sydongsun 发表于 2013-11-29 16:19
在你安装软件版本的install master guide应该有这样的说明的。

查过了，应该木有问题。
比较奇怪的是ORALCE数据库没起来。
手工启动了ORACLE数据库，并且打了个数据库的补丁

w39

换了台机器，20G内存，看看效果如何

w39

启动电脑以后手工连接数据库，提示：shared memory realm does not exist
但可以手动启动数据库。
不知道是不是数据库有问题。
11203的数据库，要打哪些数据库补丁吗？

sydongsun

11.2的一些版本，有几个关键的数据库补丁必须要打上的。文档中应该有说的。是否按照文档把数据库补丁打上了么？

w39

sydongsun 发表于 2013-12-2 16:47
11.2的一些版本，有几个关键的数据库补丁必须要打上的。文档中应该有说的。是否按照文档把数据库补丁打上了 ...

不知道呢
做这系统的BASIS离职了.......
理论上说，应该打上了的