金蝶云星空K3 Cloud V7.2_Oracle数据库安装及运维工作指南

金蝶云星空

ORACLE 数据库安装及完善工作要求

2018-06-27张华福

金蝶软件（中国）有限公司

金蝶云星空基础系统部

时间

2018-02-01 18:05

2018-03-22 16:20

2018-04-19 10:29

2018-04-19 10:33

2014-04-23 14:30

2018-04-25 18:10

2018-04-26 08:38

2018-05-30 18:03

2018-06-27 11:08

位置

2 数据库安装创建

6 创建合适的表空间

2 数据库安装创建

2 数据库安装创建

2数据库安装创建

4.4 删除临时表信息

4.2 采集统计信息

2 数据库安装创建

2 数据库安装创建

内容

添加补丁号16086769

添加6.1

添加补丁号 17306264

修改最新补丁集号

添加：提示。

添加：EXEC 动态语句

添加：采集索引统计信息

添加补丁号 16311211_

14275161;22113854;19855835;19174639;

24739928;23665623;20907061;18498878;

作者

张华福

张华福

张华福

张华福

张华福

张华福

崔智刚

张华福

张华福

本文主要强调 ORACLE 数据库服务器环境的安装软件及版本，以及安装完成后的后续完善

工作。以确保数据库以比较健壮的状态投入生产，尽量避免已知的问题影响生产库的运营。文章不涉及到软件的安装方法步骤。

1 服务器系统软件，数据库版本安装推荐：

1 数据库服务器的操作系统，推荐使用 ORACLE LINUX6.9。

2 数据库软件版本，要求安装11204企业版（不支持标准版），单节点或RAC环境均可，

推荐使用RAC。

2 数据库安装创建完毕后，需要进行下列的完善工作，

1 打上最新的补丁集，如：ORACLE 11204，截止至 2018年04月，ORACLE11204 数据库, 当

前最新版本的补丁集为 20180417 日发布（使用CSI服务号，到ORACLE的SUPPRT网站

下载）,此外，还需要打上下列小补丁（ONE-OFF PATCH）：14275161，

16086769_112041，16311211_，17306264_，

18841764，18498878_112040，19174639_112040，19678658_，

19692824(使用linux7时才需要)， 19855835_112044，20907061_，

22113854_112040，23665623_，24739928_，24921392，

p27475913_112040_ -- GI 版本,

p27338049_112040_ -- 纯数据库版。

提示：1 PSU补丁集在单节点环境使用纯数据库版，在RAC 环境使用GI版本。

2 优先打补丁集（强烈建议），再打小补丁（建议）。

3 解压后，请按照解压出来的 /txt 文档（解压目录里）说明安装。

4 有时补丁集和小补丁可能会存在冲突，如：在打补丁19678658前，做补丁间冲突检查，

[oracle@rac12 /backup/soft/p19678658/19678658]

$opatch prereq CheckConflictAgainstOHWithDetail -ph ./

此时，该命令的反馈结果，可能会包含类似这种信息： （Conflict with Composite Patch 27338049），

遇上这种情况，通常得再到SUPPORT 网站，寻找该补丁的最新补丁集，如上：19678658_

补丁19678658 和 27338049 集有冲突，但19678658_和该补丁集没有冲突，此时，得选择后者来

打。如下检查：

[oracle@rac11 /backup/soft/opatch/p19678658_/19678658]

$opatch prereq CheckConflictAgainstOHWithDetail -ph ./

Oracle Interim Patch Installer version 11.2.0.3.19

Copyright (c) 2018, Oracle Corporation. All rights reserved.

PREREQ session

Oracle Home : /home/app/11.2.4/product/db_1

Central Inventory : /home/app/oraInventory

from : /home/app/11.2.4/product/db_1/

OPatch version : 11.2.0.3.19

OUI version : 11.2.0.4.0

Log file location : /home/app/11.2.4/product/db_1/cfgtoollogs/opatch/opatch2018-06-01_09-39-55AM_

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

[oracle@rac11 /backup/soft/opatch/p19678658_/19678658]

$

5 当往rac 环境打补丁16311211_后，数据库将无法MOUNT。原因：控制文件放在ASM的某个DISKGROUP上，而该DISKGROUP 的GROUP 为 asmadmin，与 数据库软件的安装属主（通常都是 oracle账户），下的 $ORACLE_HOME/bin/oracle，该文件的 group 不一样，该文件的 group 此时一般为 oinstall，故导致

$ORACLE_HOME/bin/oracle 报权限不足，无法读取该diskgroup 上的控制文件，故，无法启动数据库。

解决方法如下演示（文档 ID 1378747.1）：

[oracle@rac11 /backup/soft/opatch]

$cd $ORACLE_HOME/bin

[oracle@rac11 /home/app/11.2.4/product/db_1/bin]

$ls -lrt oracle

-rwsr-s--x 1 oracle oinstall 239837496 May 30 17:22 oracle <-------------- 经分析，是因为 oracle 文件的属于从

asmadmin 变成 oinstall 的原因

[oracle@rac11 /home/app/11.2.4/product/db_1/bin]

$exit

logout

[root@rac11 ~]

#su - grid

Last login: Wed May 30 14:44:28 CST 2018 on pts/2

[grid@rac11 ~]

$cd $ORACLE_HOME/bin <--------------- 来到 grid 账户的此目录下，执行下面的操作

[grid@rac11 /home/app/11.2.4/grid/home/bin]

$./setasmgidwrap o=/home/app/11.2.4/product/db_1/bin/oracle <--------------- 修改

oracle 文件的属主（数据库软件的安装属主（通常都是 oracle账户）的 bin 目录下的 oracle 文件）

[grid@rac11 /home/app/11.2.4/grid/home/bin]

$ls -lrt /home/app/11.2.4/product/db_1/bin/oracle

-rwsr-s--x 1 oracle asmadmin 239837496 May 30 17:22 /home/app/11.2.4/product/db_1/bin/oracle

所有节点都要重复上述操作，之后即可正常启动数据库。

若看不懂这一条，那就不要往 RAC 环境打补丁

16311211_。

6 上面列举的小补丁（如：16311211），尽量寻找发布时间晚的补丁，因为，早先的版本，可能存在与PSU补丁集冲突的情况，而后面出的版本，则可能已经解决了此冲突。如补丁：16311211，会与20180417补丁集冲突；但若是16311211_，还是同一补丁，但不会与上述补丁集冲突。

2 初始化参数，下面的参数值，只是通常情况下的设置（或可根据服务器的硬件条件自行

修改配置），要想系统效率最优，得依据数据库实际的运行情况逐步作微调。

2.1 给数据库服务器配置 HugePgaes，详见文档：

如何给 linux 环境下的 oracle 数据库服务器设置 HugePages.

2.2 修改数据库参数：

alter profile default LIMIT PASSWORD_LIFE_TIME UNLIMITED;

alter system set processes=600 scope=spfile sid='*';

alter system set control_file_record_keep_time=21 scope=spfile sid='*';

alter system set open_cursors=300 scope=spfile sid='*';

alter system set session_cached_cursors=300 scope=spfile sid='*';

alter system set audit_trail=NONE scope=spfile sid='*';

alter system set recyclebin=off scope=spfile sid='*';

alter system set log_archive_dest_1='location=use_db_recovery_file_dest'

scope=both sid='*';

alter system set fast_start_mttr_target = 300 scope=both sid='*';

alter system set streams_pool_size=100m scope=spfile sid='*';

alter system set archive_lag_target = 1200;

alter system set "_optimizer_use_feedback"= false scope=spfile sid='*';

alter system set "_optimizer_invalidation_period"=60 scope=both sid='*';

alter system set db_securefile=always scope=both sid='*';

alter system set filesystemio_options=setall scope=spfile sid=’*’;

修改结束后，需重启数据库，才能确保上述修改生效。

3 将数据库设置成归档模式，并开启最小附加日志，如下操作：

3.1 启用 db_reocvery_file_dest 参数，设置好归档日志存放路径，

SYS@k3db1>show parameter db_recovery

NAME TYPE VALUE

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

db_recovery_file_dest string

db_recovery_file_dest_size big integer 0

SYS@k3db1>alter system set db_recovery_file_dest_size=50g; -- 此参数值按实际情况设置。

System altered.

Elapsed: 00:00:00.04

SYS@k3db1>alter system set db_recovery_file_dest='+FLASH'; -- 此参数值按实际情况设置。

System altered.

Elapsed: 00:00:00.03

alter system set log_archive_dest_1='location=use_db_recovery_file_dest'

scope=both sid='*';

同时在两节点上执行：关闭数据库，设置归档模式，都设置了归档模式后，再打开库。

2 节点1，节点2上。

Shutdown immediate;

3 节点1，节点2上。

Startup mount;

4 节点1，节点2上。

Alter database archivelog;

Alter database add supplemental log data;

-- 开启最小附加日志

Alter database add supplemental log data;

5 节点1，节点2上。

Alter database open;

4 制定作业，定时采集系统表，业务表的统计信息，

4.1使用 sqlplus 工具，以 sys 身份，登录生产库，创建定时作业（下同），采集系统表，

每天早上5点（按需求更改）运行。

Create or replace procedure pro_analyze_dict as

begin

dbms__dictionary_stats();

dbms__fixed_objects_stats();

End pro_analyze_dict;

/

Begin

dbms__job

(job_name => 'JOB_ANALYZE_DICT',

job_type => 'PLSQL_BLOCK',

job_action => 'BEGIN pro_analyze_dict; END;',

repeat_interval => 'FREQ=DAILY; BYHOUR=05; BYMINUTE=5;',

enabled => true);

End;

/

4.2 创建采集业务表的定时作业，每天早上1点（按需求更改）运行。

Create or replace procedure pro_analyze_stats as

ora_20005 exception;

ora_25191 exception;

pragma exception_init(ora_20005,-20005);

pragma exception_init(ora_25191,-25191);

/*

ORA-25191: cannot reference overflow table of an index-organized table

ORA-20005: object statistics are locked (stattype = ALL)

*/

begin

-- 2017-11-03 10:46

Dbms__database_monitoring_info();

for i in (select username from dba_users where username in ('K3CLOUD3','K3CLOUD')) loop

for j in (select owner, '"'||table_name||'"' table_name from dba_tables a where owner in

(me) and temporary='N'

and table_name not like 'TMP%' and not exists (select 1 from dba_mview_logs

where log_owner in (me)

and log_table=_name) order by owner, last_analyzed nulls first) loop

begin

dbms__table_stats(,_name,method_opt=>'for all columns size

254',degree=>2, casacde=>true);

exception

when ora_20005 or ora_25191 then

null;

end;

end loop;

-- 2017-10-09 10:36 gather virtual column stats

for j in (select owner, '"'||table_name||'"' table_name, column_name from dba_tab_cols

where owner in (me) and virtual_column='YES'

and table_name not like 'TMP%' and data_type<>'XMLTYPE' and

hidden_column='NO') loop

begin

dbms__table_stats(,_name,method_opt=>'for columns

'||_name||' size 254 ',casacde=>true);

exception

when ora_20005 or ora_25191 then

null;

end;

end loop;

end loop;

End pro_analyze_stats;

/

Begin

dbms__job

(job_name => 'JOB_ANALYZE_STATS',

job_type => 'PLSQL_BLOCK',

job_action => 'BEGIN pro_analyze_stats; END;',

repeat_interval => 'FREQ=DAILY; BYHOUR=01; BYMINUTE=30;',

enabled => true);

End;

/

说明：红色部分，改为要存放业务数据的账户名（下同）。

--4.3 创建一作业，每天早上3点（按需求更改）删除过期（24小时以前创建）的临时表

-- 创建删除临时表的过程。

create or replace procedure pro_purge_tmptable as

ora_942 exception;

pragma exception_init(ora_942, -942);

ora_54 exception;

pragma exception_init(ora_54, -54);

v_msg varchar2(300);

begin

for i in (select username from dba_users where username in ('K3CLOUD3','K3CLOUD')) loop

for j in (select , _name from dba_tables a, dba_objects b

where in (me) and _name like 'TMP%' and

length(_name) = 30

and in (me) and _type='TABLE' and _name

like 'TMP%' and d < (sysdate - 1)

and (= and _name=_name) ) loop

begin

--dbms__line(_name);

execute immediate 'drop table '||||'.'||_name||' purge';

exception

when others then

null;

end;

end loop;

begin

execute immediate 'delete from '||me||'.t_bas_temporarytablename a where

not exists (select 1 from dba_tables where owner='''||me||''' and

table_name=name)';

commit;

end;

end loop;

end pro_purge_tmptable;

/

Begin

dbms__job

(job_name => 'JOB_PURGE_TMPTABLE',

job_type => 'PLSQL_BLOCK',

job_action => 'BEGIN pro_purge_tmptable; END;',

repeat_interval => 'FREQ=DAILY; BYHOUR=03; BYMINUTE=0;',

enabled => true);

End;

/

说明：脚本中，红色部分，是用于业务运营的数据库账户。

2, 据我了解，这些临时表都应该记录在该账户下的：T_BAS_TEMPORARYTABLENAME

此表中。但由于该表中对临时表的创建时间，FCREATEDATE字段，没有强制 NOT NULL，

我担心某些记录没时间，这样，若读取该表的数据来做删除操作，这些没时间的记录，

将被漏掉。

SYS@orcl>desc t_bas_temporarytablename

Name Null? Type

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

FTABLENAME NOT NULL VARCHAR2(30)

FCREATEDATE DATE

FUSERTOKEN VARCHAR2(36)

FPROCESSTYPE NUMBER(10)

FUSERTRANSACTIONID VARCHAR2(200)

--4.4 创建一作业，每30分钟运行一次，删除5分钟前采集的临时表的统计信息。

Create or replace procedure pro_delete_tm_stats as

ora_20005 exception;

pragma exception_init(ora_20005, -20005);

begin

for i in (select owner, table_name, last_analyzed, num_rows from dba_tables where owner in

('K3CLOUD3','K3CLOUD') and temporary='Y'

and last_analyzed is not null and last_analyzed < (sysdate - 1/288) order by owner,

table_name) loop

begin

dbms__table_stats(,_name,no_invalidate=>false);

--for 12c, 2018-04-25 18:10

execute immediate 'analyze table '||||'.'||_name||' delete statistics';

exception

when ora_20005 then

null;

end;

end loop;

End;

Begin

dbms__job

(job_name => 'JOB_DELETE_TM_STATS',

job_type => 'PLSQL_BLOCK',

job_action => 'BEGIN PRO_DELETE_TM_STATS; END;',

repeat_interval => 'FREQ=MINUTELY;INTERVAL=30;',

enabled => true);

End;

/

4.5 关闭系统自带的统计信息等功能。

exec dbms_auto_task_e(client_name => 'auto space advisor', operation =>

NULL, window_name => null);

exec dbms_auto_task_e(client_name => 'sql tuning advisor',operation =>

null, window_name => null);

exec dbms_auto_task_e(client_name => 'auto optimizer stats collection',

operation => NULL, window_name => NULL);

5 制定合适的备份策略，

5.1 通常情况下，我们都是以物理备份为主，逻辑备份为辅，也就是，主要使用 rman

备份，同时辅以 expdp 导出备份。

5.2 对于 rman 的备份策略，基本有两者：

5.2.1 保留几份全库备份（包括全库备份以后的所有日志，以保障可用该备份恢复

自该备份以来的任意时间点），但此策略只要求有备份，不保障能往回追溯

N天以来，故，不常用。

5.2.2 保留恢复最近N天以来的备份。使用此策略，可以保障备份集，可以恢复

从现在开始，往回追溯 N 天以来的任意时间点。这是最常用的备份保留策略，

基本上，我们都使用此策略。

5.2.3 对于需要保留 N天 以来的备份策略，需要依据甲方的业务需求来制定。

比如：甲方要求，需要保留一个月以来的备份数据，也就是，从现在开始，往

回追溯 31 天以来，这个范围内的任意时间点，都必须可以恢复。

5.2.4 保留 N 天以来的备份集，消耗的是备份集的存放空间，因此，若磁盘存储不

足，得向甲方说明，要求甲方配备足够的磁盘空间（需考虑后续库数据量的持

续增长情况）。

5.2.5 若有条件给生产库搭建DataGuard 环境，建议启动 DG 库的数据库闪回功能。

默认情况下，DG库能够闪回最近24小时以内任意时间点的数据。

5.3 制定好备份策略后，需要持续观察至少一个备份周期的时间，以确保备份策略进入

正常的循环工作状态。

对于生产数据库，备份重于一切。我们要求，自生产系统投入使用开始，就必须确保

备份策略进行良性运行工作状态，DBA需要根据生产系统的运行情况，制定合理的巡

检计划，检查包括备份策略在内的运行状态，以策安全。

6 创建合适的表空间，

6.1 新建的表空间必须是本地空间管理方式（LMT），不可以DMT。同时，建议使用

默认的 ASSM 段管理方式，因为SECUREFILE LOB字段，无法保存在以MSSM

方式的段管理表空间下（ORA-43853）。

6.2 不同的数据库账户，创建各自的表空间，也就是，该表空间只用于存放该账户的

数据对象。

6.3 表空间通常分3类，1 数据表空间， 2 索引表空间，3 LOB 数据类型表空间。

顾名思义，数据表空间存放数据，索引表空间存放索引，LOB表空间存放该账户下

所有 LOB 类型的字段，也就是，从各表中，领出该字段迁移到此表空间上。

6.4 当生产系统运行一段时间后，可能会出现尺寸比较大的表，可考虑为这些大表创建

新的表空间 （EXTENT 值放大些，比如：100M,500M,1G等），建好后，采用在线

重定义的方法迁移。

6.5 后续若对表作分区，可针对大表创建新的数据表空间，和索引表空间，比如：创建

EXTENT=100M的数据表空间（存放表分区），EXTENT=50M的索引表空间（存放

分区索引）。EXTENT的尺寸多少适合，得看实际表的情况，也可以不止建一套，

可建多套。

7 推荐使用最新版本的ORACHK工具（到ORACLE 的SUPPORT 网站下载）检查数据库环境

的当前状况，并根据该工具的检查报告，做合适的修改。