Oracle Single 환경에 OCW Patch 를 적용해야 할까?

기본적으로 19.3 버전을  초기 설치하게 되면 non RAC / non ASM 환경임에도 
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) 해당 패치가 같이 설치가 된다.

이후 Patch 관리를 해줘야 할 떄, Database RU 외에 OCW (Grid)도 같이 해 줘야 하나? 하는 의문이 생긴다.

-> 결론부터 말하면 선택사항이며 오라클에서는 보안패치가 포함되어 있기 때문에 같이 해줄것을 권장하고 있다.
-> 같이 관리해 주고 싶다면 GI RU 를 받아서 OCW와 DB RU를 개별적으로 Patch 적용해 주면 된다.

==========================================================================

APPLIES TO:

Oracle Database - Enterprise Edition - Version 19.3.0.0.0 and later
Information in this document applies to any platform.

GOAL

Is it or not necessary to apply OCW patches on my ORACLE_HOME even if I don't use ASM, RAC or CLUSTERWARE?

It is optional, but even if no GI Stack (ASM, Clusterware or RAC) is used inside the server, it is recommended not to ignore the security patches of the installed components. And apply the most recent OCW Patch.

From version 19c onwards, the Patch 29585399 OCW RU is included from the initial installation.  

[oracle@localhost ~]$ opatch lspatches
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
29517242;Database Release Update : 19.3.0.0.190416 (29517242) 

OPatch succeeded. 

 

SOLUTION

To apply the latest OCW patch, it is necessary to do it manually. This must be done by downloading the latest GI RU patch, unzipping it and placing it in the directory corresponding to the OCW and apply it using "opatch apply". 

Applying OCW and DB RUs 

Patch 35319490: GI RELEASE UPDATE 19.20.0.0.0.0 will be used.

You can download it from the following link:
https://updates.oracle.com/download/35319490.html 

NOTE: For rollback, installation, and post-installation instructions refer to README of the respective patches.

[oracle@localhost ~]$ unzip p35319490_190000_Linux-x86-64.zip

[oracle@localhost ~]$ cd 35319490/35320149 ◄◄◄ OCW Patch ID
[oracle@localhost ~]$ opatch apply
Patch 35320149 successfully applied.
OPatch succeeded.
[oracle@localhost ~]$ cd cd 35319490/35320081 ◄◄◄ DB RU Patch ID
[oracle@localhost ~]$ opatch apply

Patch 35320081 successfully applied.
OPatch succeeded.

Proceed to start the database and execute datapatch
SQL> startup
SQL> exit
[oracle@localhost ~]$ datapatch -verbose
SQL Patching tool complete on Sat Aug 26 21:29:07 2023 
[oracle@localhost ~]$ opatch lspatches
35320081;Database Release Update : 19.20.0.0.230718 (35320081)
35320149;OCW RELEASE UPDATE 19.20.0.0.0 (35320149)
OPatch succeeded.
[oracle@localhost ~]$

 

Already updated OCW and DB Release Update to the latest version

Posted by pat98

공식적인 방법은 아니니 에디션별 기능 등을 quick 하게 테스트 해야 할 경우 해 볼수 있겠다.

 

- Enterprise -> Standard 로 변경. shutdown relink

 

cd $ORACLE_HOME/rdbms/lib

make -f ins_rdbms.mk edition_standard ioracle

 

Connected to:

Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production

Version 19.3.0.0.0

 

select * from v$option where parameter='Partitioning';

 

PARAMETER            VALUE          CON_ID

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

Partitioning         FALSE                0

 

- Standard -> Enterprise 로 변경. shutdown relink

 

cd $ORACLE_HOME/rdbms/lib

make -f ins_rdbms.mk edition_enterprise ioracle

 

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.3.0.0.0

 

 

PARAMETER            VALUE          CON_ID

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

Partitioning         TRUE                0

 

- 현재  ins_rdbms.mk 화일에 code 되어 있는 내용은 아래와 같음

 

grep -i edi /oracle/app/oracle/product/19.0.0/rdbms/lib/ins_rdbms.mk

 

edition_corestandard:

        $(SILENT)$(ECHO) "Deploying Oracle Database Core Standard Edition"

edition_coreenterprise:

        $(SILENT)$(ECHO) "Deploying Oracle Database Core Enterprise Edition"

edition_standard:

        $(SILENT)$(ECHO) "Deploying Oracle Database Standard Edition"

edition_enterprise:

        $(SILENT)$(ECHO) "Deploying Oracle Database Enterprise Edition"

edition_highperf:

        $(SILENT)$(ECHO) "Deploying Oracle Database Enterprise Edition High Performance"

edition_extremeperf:

        $(SILENT)$(ECHO) "Deploying Oracle Database Enterprise Edition Extreme Performance"

edition_express:

        $(SILENT)$(ECHO) "Deploying Oracle Database Express Edition"

Posted by pat98

2024. 2. 20. 23:22 내가 읽은 책

희랍어 시간


 

시력을 잃어 가는 남자

청력을 잃어 말하지 못하는 여자

소설의 줄거리는 중요하지 않다. 두 사람이 만나는 이야기 이지만 사랑이라 부를수 있을까?

때로는 침묵이 더 효과적인 언어수단이며 고요한 적막이 우리에게 커다란 울림을 느끼게 한다. 

Posted by pat98

Exadata 이미지 업그레이드 작업 버그 하나 (22.1.17, 23.1.8)

Issue: During OS Image Upgrade, node gets into boot loop

Impacted releases: Direct upgrade from 21.2.10 or earlier to 22.1.17 / 22.1.18 / 22.1.19 / 23.1.8 /23.1.9 / 23.1.10

Root Cause :
There is a known bug in kernel-ueknano-4.14.35-2047.511.5.5.3.el7uek.x86_64 Kernel due to which FW update of Whitney+ card crashes Kernel.
Above Kernel is included in Nov-2023 releases (22.1.17, 23.1.8).
Bug 35844212/35848949 - bnxtnvm failed to update/downgrade whitneyplus firmware
Fix for above bug is included in uptrack-update that is also included in Nov-2023 releases.
While upgrading compute during firstboot, it comes up with new Kernel and FW updates are applied.
There is no issue if FW upgrade activity starts after botting up with new Kernel and uptrack update is effective.
Due to timing issues, if FW upgrade starts after booting up with new Kernel and before uptrack-update is effective, then kernel crashes and node gets rebooted.
During boot up time (firstboot), FW upgrade kicks in again causes Kernel to crash. This is happening in a loop forever.

Workaround:
• Disable FW updates during impacted upgrade path ( touch /opt/oracle.cellos/DISABLE_HARDWARE_FIRMWARE_CHECKS)
• Post upgrades, install FW upgrades
o rm /opt/oracle.cellos/DISABLE_HARDWARE_FIRMWARE_CHECKS
o /opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact
Next steps:
Kernel with fix is included in Feb-2024 releases (22.1.20, 23.1.11).

Posted by pat98


CRS-2717: Server '<hostname>' is not in any of the server pool(s) hosting resource 'ora.<sid>.db'

Resources Unable to be Started on a Given Cluster Node (Doc ID 2122592.1)


- 증상 

startup 했는데 뜬금없이 resource 에 등록되어 있지 않다고 에러발생

srvctl 명령어 에러시

<root_user>@node2:# <ORACLE_HOME>/srvctl start instance -db <dbname> -node <hostname>
PRCR-1013 : Failed to start resource ora.<sid>.db
PRCR-1064 : Failed to start resource ora.<sid>.db on node node2
CRS-2717: Server '<hostname>' is not in any of the server pool(s) hosting resource 'ora.<sid>.db'

startup 명령어 에러시

SQL> startup
ORA-39510: CRS error performing start on instance <instance name?
CRS-2549: Resource <resource name> cannot be placed on <node name> as it is not a valid candidate as per the placement policy
CRS-0223: Resource <resource name> has placement error.


<GI_HOME>/bin/crsctl stat res ora.crsd -f -init | grep RESOURCE_USE_ENABLED
RESOURCE_USE_ENABLED=0

정상적이면 이 값은 1이 되어야 한다.


- 원인
Bug 23733697 에 의한 것으로 rootcs.pl -prepatch 로 패치하는 동안 임시로 값을 0 으로 만드는데 작업이 중단/실패되거나 했을 경우 다시 0 -> 1로 바꾸어야 하는데 그러지 못하고 0 상태로 원복하지 못함.

<GI_HOME>/bin/crsctl set resource use 1
위와 같이 조치하고 CRS 재기동

crsctl stop crs
crsctl start crs

 

정상확인 !!

Posted by pat98

사실상 미국인 이지만 돌아가신 한국인 엄마의 한국음식을 통해 한국인의 정서를 더 많이 알고 있는 저자의 이야기.

Posted by pat98

패치작업 19.22.0.0.240116 (GI PSU 35940989)

Database Patch Set Update : 19.22.0.0.240116 (35943157)
OCW Patch Set Update      : 19.22.0.0.240116 (35967489)
ACFS Patch Set Update     : 19.22.0.0.240116 (35956421)
Tomcat Release Update     : 19.0.0.0.0       (36115038)
DBWLM Release Update      : 19.0.0.0.0       (33575402)

Oracle Grid Infrastructure Patch Set Update 19.22.0.0.240116 
-------------------------------------
GI_HOME, ORACLE_HOME 을 개별로 각각 할때

- grid 유저
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/35943157
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/35967489
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/35956421
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/33575402
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/36115038

- oracle 유저
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/35943157
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <UNZIPPED_PATCH_LOCATION>/35940989/35967489

(oracle)
$ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>

(root 유저)
export GI_HOME=/u01/app/19.0.0.0/grid
$GI_HOME/crs/install/rootcrs.sh -prepatch 

(grid 유저)
export GI_HOME=/u01/app/19.0.0.0/grid
cd /u01/install
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./35940989/35967489 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./35940989/35956421 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./35940989/35943157 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./35940989/33575402 -silent
$GI_HOME/OPatch/opatch apply -oh $GI_HOME -local ./35940989/36115038 -silent

(oracle 유저)
export ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/dbhome_1
cd /u01/install
./35940989/35967489/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local ./35940989/35967489 -silent
$ORACLE_HOME/OPatch/opatch apply -oh $ORACLE_HOME -local ./35940989/35943157 -silent
./35940989/35967489/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME 

(root 유저)
export GI_HOME=/u01/app/19.0.0.0/grid
$GI_HOME/rdbms/install/rootadd_rdbms.sh
$GI_HOME/crs/install/rootcrs.sh -postpatch 

(oracle)
$ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name> 

- Loading Modified SQL Files into the Database
sqlplus /nolog
SQL> conect / as sysdba
SQL> startup
SQL> quit
cd $ORACLE_HOME/OPatch
./datapatch -verbose

### [롤백하는 경우] ###########

(oracle)
$ <ORACLE_HOME>/bin/srvctl stop home -o <ORACLE_HOME> -s <status file location> -n <node name>

GI Home
(root로)
$GI_HOME/crs/install/rootcrs.sh -prepatch -rollback

(grid 유저로)
export GI_HOME=/u01/app/19.0.0.0/grid
cd /u01/install
$GI_HOME/OPatch/opatch nrollback -local -id 35967489,35956421,35943157,33575402,36115038 -oh $GI_HOME -silent

(oracle 유저로)
export ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/dbhome_1
cd /u01/install
./35940989/35967489/custom/scripts/prepatch.sh -dbhome $ORACLE_HOME 
$ORACLE_HOME/OPatch/opatch nrollback -local -id 35967489,35943157 -oh /u01/app/oracle/product/19.3.0.0/dbhome_1 -silent
./35940989/35967489/custom/scripts/postpatch.sh -dbhome $ORACLE_HOME

Run post script
(root로)
export GI_HOME=/u01/app/19.0.0.0/grid
$GI_HOME/rdbms/install/rootadd_rdbms.sh
$GI_HOME/crs/install/rootcrs.sh -postpatch -rollback

(oracle)
$ <ORACLE_HOME>/bin/srvctl start home -o <ORACLE_HOME> -s <status file location> -n <node name>

sqlplus /nolog
SQL> conect / as sysdba
SQL> startup
SQL> quit
cd $ORACLE_HOME/OPatch
./datapatch -verbose

Posted by pat98

처음 온 공항이라 기록용으로 저장한다.

 

서울 인천 (ICN) -> 미국 댈러스(DFW) -> 미국 멤피스(MEM) 행이다.

 

환승시간이 2시간 밖에 되지 않아 살짝 걱정되었는데, 우려와 달리 비교적 힘들지 않게 환승 가능했다. (환승 대기시간은  3시간 추천한다. 물론 동선이 익숙하거나 아는 공항이면 환승시간은 짧은게 당연 좋다.)

-> 대한항공을 탔음에도 미국은 국제선 -> 국내선으로 환승하면 짐을 내가 다시 직접 부쳐야 했다.

 

1. 비행기 내리면 사람들 따라서 쭈욱 나간다. (거리가 상당히 되지만 내가 맞게 가나 의심할 필요가 전혀 없다)

2. 입국심사장 도착하면 외국인 라인에서 입국 심사를 받는다. 라인이 10개 정도 열려 있었다.(어디가냐고 한개만 물어봤음 -> Pass)

3. Baggage Claim 2번에서 먼저 짐을 찾는다. (이때 대한항공 직원에게 문의하면 이런 종이한장을 주신다. 이거 보고 가면 난이도 급하강) 

-> 난  모닝캄 회원이였는데 Priority Line 이라고 되어 있는 팻말앞에 먼저 처리되어서 있어서 그냥 끌고가서 편했다. 

 

 

4. Baggage Claim 4번과 5번 사이 통로로 이동한후 ALL CONNECTION BAGS에 내 짐을 다시 올려 놓으면 최종 목적지 멤피스까지 수하물은 알아서 간다.

 

5. 다시 3층으로 올라서 귀찮지만 Security Check 를 또 하고 통과하면 내가 갈 터미널 확인해서 SYKLINK (트램 같은것) 타고 내가 갈 터미널로 이동해 준다. (이떄 중요한 것은 최종 터미널과  게이트가 자주 바뀌므로 반드시 재확인 해야 한다.)

-> 나 같은 경우 대한항공에서 발급해준 종이티켓의 정보는 진작에 바뀌었고, 다시 보안검색 통과하자 마자 Information Machine 에서 다시 티켓 SCAN 했더니 바뀌어서 B45로 가고 있었는데 가는중에 American Airline  App에서 B19로 바뀌었다고 해서 중간에 급하게 내렸다.)

 

6. 내 경우에는 B19 게이트에서 기다리는데 국내선이라 앞에 도착하는 비행기가 연착하느라 출발 30분 전인데도 내가 갈 비행기 정보가 전혀 나오지 않았다. (앞에 안내직원도 계속 다른 업무로 통화중이다 ㅠ.ㅠ) 결국 출발 10분전 쯤에 멤피스행 비행기 Delay 된다고 화면에 표시되었고 안도 하면서 비행기를 탈수 있었다.

 

7. 멤피스는 도착해서 한층 내려가면 렌트카 센터가 있고, 쭈욱 표시 따라서 가면 된다.

 

환승기 끝.

Posted by pat98

 

코맥 메카시의 국경 3부작 중 첫번째 작품 (1992년)

서부평원의 서정적인 풍경묘사가 좋고 문체가 호흡이 길면서 유려하다.

일종의 성장소설로 보면 될것 같고, 내용 자체는 드라마틱한 사건은 없기 때문에 

메카시의 여타 후기작인 카운셀러나 노인을 위한 나라는 없다 등에서 보이는

잔혹한 묘사 등은 없다..

근데 번역하기 상당히 힘들었을 듯..

Posted by pat98

SET SERVEROUTPUT ON
SET LINES 600
ALTER SESSION SET NLS_DATE_FORMAT = 'DD/MM/YYYY HH24:MI:SS';

DECLARE
    v_analyse_start_time    DATE := SYSDATE - 7;
    v_analyse_end_time      DATE := SYSDATE;
    v_cur_dt                DATE;
    v_undo_info_ret         BOOLEAN;
    v_cur_undo_mb           NUMBER;
    v_undo_tbs_name         VARCHAR2(100);
    v_undo_tbs_size         NUMBER;
    v_undo_autoext          BOOLEAN;
    v_undo_retention        NUMBER(6);
    v_undo_guarantee        BOOLEAN;
    v_instance_number       NUMBER;
    v_undo_advisor_advice   VARCHAR2(100);
    v_undo_health_ret       NUMBER;
    v_problem               VARCHAR2(1000);
    v_recommendation        VARCHAR2(1000);
    v_rationale             VARCHAR2(1000);
    v_retention             NUMBER;
    v_utbsize               NUMBER;
    v_best_retention        NUMBER;
    v_longest_query         NUMBER;
    v_required_retention    NUMBER;
BEGIN
    select sysdate into v_cur_dt from dual;
    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('- Undo Analysis started at : ' || v_cur_dt || ' -');
    DBMS_OUTPUT.PUT_LINE('--------------------------------------------------');

    v_undo_info_ret := DBMS_UNDO_ADV.UNDO_INFO(v_undo_tbs_name, v_undo_tbs_size, v_undo_autoext, v_undo_retention, v_undo_guarantee);
    select sum(bytes)/1024/1024 into v_cur_undo_mb from dba_data_files where tablespace_name = v_undo_tbs_name;

    DBMS_OUTPUT.PUT_LINE('NOTE:The following analysis is based upon the database workload during the period -');
    DBMS_OUTPUT.PUT_LINE('Begin Time : ' || v_analyse_start_time);
    DBMS_OUTPUT.PUT_LINE('End Time   : ' || v_analyse_end_time);
    
    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Current Undo Configuration');
    DBMS_OUTPUT.PUT_LINE('--------------------------');
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace',55) || ' : ' || v_undo_tbs_name);
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (datafile size now) ',55) || ' : ' || v_cur_undo_mb || 'M');
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (consider autoextend) ',55) || ' : ' || v_undo_tbs_size || 'M');
    IF V_UNDO_AUTOEXT THEN
        DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : ON');  
    ELSE
        DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : OFF');  
    END IF;
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo retention',55) || ' : ' || v_undo_retention);

    IF v_undo_guarantee THEN
        DBMS_OUTPUT.PUT_LINE(RPAD('UNDO GUARANTEE is set to',55) || ' : TRUE');
    ELSE
        dbms_output.put_line(RPAD('UNDO GUARANTEE is set to',55) || ' : FALSE');
    END IF;
    DBMS_OUTPUT.PUT_LINE(CHR(9));

    SELECT instance_number INTO v_instance_number FROM V$INSTANCE;

    DBMS_OUTPUT.PUT_LINE('Undo Advisor Summary');
    DBMS_OUTPUT.PUT_LINE('---------------------------');

    v_undo_advisor_advice := dbms_undo_adv.undo_advisor(v_analyse_start_time, v_analyse_end_time, v_instance_number);
    DBMS_OUTPUT.PUT_LINE(v_undo_advisor_advice);

    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Undo Space Recommendation');
    DBMS_OUTPUT.PUT_LINE('-------------------------');

    v_undo_health_ret := dbms_undo_adv.undo_health(v_analyse_start_time, v_analyse_end_time, v_problem, v_recommendation, v_rationale, v_retention, v_utbsize);
    IF v_undo_health_ret > 0 THEN
        DBMS_OUTPUT.PUT_LINE('Minimum Recommendation           : ' || v_recommendation);
        DBMS_OUTPUT.PUT_LINE('Rationale                        : ' || v_rationale);
        DBMS_OUTPUT.PUT_LINE('Recommended Undo Tablespace Size : ' || v_utbsize || 'M');
    ELSE
        DBMS_OUTPUT.PUT_LINE('Allocated undo space is sufficient for the current workload.');
    END IF;
    
    SELECT dbms_undo_adv.best_possible_retention(v_analyse_start_time, v_analyse_end_time) into v_best_retention FROM dual;
    SELECT dbms_undo_adv.longest_query(v_analyse_start_time, v_analyse_end_time) into v_longest_query FROM dual;
    SELECT dbms_undo_adv.required_retention(v_analyse_start_time, v_analyse_end_time) into v_required_retention FROM dual;

    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Retention Recommendation');
    DBMS_OUTPUT.PUT_LINE('------------------------');
    DBMS_OUTPUT.PUT_LINE(RPAD('The best possible retention with current configuration is ',60) || ' : ' || v_best_retention || ' Seconds');
    DBMS_OUTPUT.PUT_LINE(RPAD('The longest running query ran for ',60) || ' : ' || v_longest_query || ' Seconds');
    DBMS_OUTPUT.PUT_LINE(RPAD('The undo retention required to avoid errors is ',60) || ' : ' || v_required_retention || ' Seconds');

END;
/

Sample Output

- Undo Analysis started at : 30/08/2013 11:08:40 -
--------------------------------------------------
NOTE:The following analysis is based upon the database workload during the period -
Begin Time : 23/08/2013 11:08:40
End Time   : 30/08/2013 11:08:40

Current Undo Configuration
--------------------------
Current undo tablespace                                 : UNDOTBS2
Current undo tablespace size (datafile size now)        : 20M
Current undo tablespace size (consider autoextend)      : 20M
AUTOEXTEND for undo tablespace is                       : ON
Current undo retention                                  : 900
UNDO GUARANTEE is set to                                : FALSE

Undo Advisor Summary
---------------------------
Finding 1:Undo Tablespace is under pressure. Recommendation 1:Size undo tablespace to 26 MB

Undo Space Recommendation
-------------------------
Minimum Recommendation           : Size undo tablespace to 26 MB
Rationale                        : Increase undo tablespace size so that long running queries will not fail
Recommended Undo Tablespace Size : 26M

Retention Recommendation
------------------------
The best possible retention with current configuration is    : 9171 Seconds
The longest running query ran for                            : 2543 Seconds
The undo retention required to avoid errors is               : 2543 Seconds

PL/SQL procedure successfully completed.
Posted by pat98

05-06 00:19
Flag Counter
Yesterday
Today
Total

글 보관함

최근에 올라온 글

달력

 « |  » 2024.5
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

최근에 달린 댓글