quarta-feira, 12 de junho de 2024

[ORACLE] Cleanup Repository Area - Oracle Database Appliance (ODA)



Hello everyone.

How are you doing?

Today, I'll share with you a simple tip about ODA.

When I need to clean the repository area, I use these steps:

But always remember:  

  • This step-by-step worked for me, but it may not work for you.
  • It's a test environment. The real life will be different, for sure.
  • This post is for study and testing as well and has no concern for performance and security best practices.

1) List your dbhomes.

# odacli list-dbhomes



2) Check the directory size (/opt).

df -h
Filesystem                          Size  Used Avail Use% Mounted on
devtmpfs                            189G  176K  189G   1% /dev
tmpfs                               189G  845M  188G   1% /dev/shm
tmpfs                               189G  4.1G  185G   3% /run
tmpfs                               189G     0  189G   0% /sys/fs/cgroup
/dev/mapper/VolGroupSys-LogVolRoot   30G  9.6G   19G  35% /
/dev/md0                            476M  123M  329M  28% /boot
/dev/sda1                           500M  8.6M  492M   2% /boot/efi

/dev/mapper/VolGroupSys-LogVolOpt    59G   45G   11G  81% /opt

/dev/mapper/VolGroupSys-LogVolU01    99G   47G   47G  51% /u01
/dev/asm/datprds-31                 370G  291G   80G  79% /u02/app/oracle/oradata/prd
/dev/asm/commonstore-31             5.0G  631M  4.4G  13% /opt/oracle/dcs/commonstore
/dev/asm/datprodp-31                2.2T  1.6T  673G  70% /u02/app/oracle/oradata/mcg
/dev/asm/redo-365                   236G  184G   53G  78% /u04/app/oracle/redo
/dev/asm/reco-8                     1.8T  865G  936G  49% /u03/app/oracle
/dev/asm/datprodmv-31                17T   17T   16G 100% /u02/app/oracle/oradata/prodmvx7hmcg
tmpfs                                38G     0   38G   0% /run/user/54325
tmpfs                                38G     0   38G   0% /run/user/1000
tmpfs                                38G     0   38G   0% /run/user/0


3) Check the repository area.

cd /opt/oracle/oak/pkgrepos

ll -lrht orapkgs/clones/
total 9.0G
-rw-r--r-- 1 root root 2.9G Jan 15  2021 db112.210119.tar.gz
-rw-r--r-- 1 root root 6.1G Feb  8  2021 grid19.tar.gz
-rw-r--r-- 1 root root  11K Feb 12  2021 clonemetadata.xml

du -sh *
38M     asr
16G     db
44M     dcsadmin
609M    dcsagent
46M     dcscli
175M    dcscontroller
32M     firmwarecontroller
48M     firmwaredisk
12M     firmwareexpander
8.6M    hmp
216M    ilom
238M    java
981M    mysql
79M     oak
585M    opatch
9.7G    orapkgs
527M    os
91M     oss
3.4M    System
302M    thirdpartypkgs
8.4M    zookeeper

4) Cleanup the repo area

# odacli cleanup-patchrepo -cl
# odacli describe-job -i "5793e96c-159e-46cc-999e-938e339e8773"



5) Check the directory size (/opt).

df -h

Filesystem                          Size  Used Avail Use% Mounted on
devtmpfs                            189G  176K  189G   1% /dev
tmpfs                               189G  845M  188G   1% /dev/shm
tmpfs                               189G  4.1G  185G   3% /run
tmpfs                               189G     0  189G   0% /sys/fs/cgroup
/dev/mapper/VolGroupSys-LogVolRoot   30G  9.6G   19G  35% /
/dev/md0                            476M  123M  329M  28% /boot
/dev/sda1                           500M  8.6M  492M   2% /boot/efi

/dev/mapper/VolGroupSys-LogVolOpt    59G   39G   18G  70% /opt

/dev/mapper/VolGroupSys-LogVolU01    99G   47G   47G  51% /u01
/dev/asm/datprds-31                 370G  291G   80G  79% /u02/app/oracle/oradata/prd
/dev/asm/commonstore-31             5.0G  631M  4.4G  13% /opt/oracle/dcs/commonstore
/dev/asm/datprodp-31                2.2T  1.6T  673G  70% /u02/app/oracle/oradata/mcg
/dev/asm/datprodp-31                2.2T  1.6T  673G  70% /u02/app/oracle/oradata/mcg
/dev/asm/redo-365                   236G  184G   53G  78% /u04/app/oracle/redo
/dev/asm/reco-8                     1.8T  866G  935G  49% /u03/app/oracle
/dev/asm/datprodmv-31                17T   17T   16G 100% /u02/app/oracle/oradata/prodmvx7hmcg
tmpfs                                38G     0   38G   0% /run/user/54325
tmpfs                                38G     0   38G   0% /run/user/1000
tmpfs                                38G     0   38G   0% /run/user/0

6) Check the repository area.

cd /opt/oracle/oak/pkgrepos

ll -lrht orapkgs/clones
total 2.9G
-rw-r--r-- 1 root root 2.9G Jan 15  2021 db112.210119.tar.gz
-rw-r--r-- 1 root root  11K Feb 12  2021 clonemetadata.xml

du -sh *
38M     asr
16G     db
44M     dcsadmin
609M    dcsagent
46M     dcscli
175M    dcscontroller
32M     firmwarecontroller
48M     firmwaredisk
12M     firmwareexpander
8.6M    hmp
216M    ilom
238M    java
981M    mysql
79M     oak
585M    opatch
3.6G    orapkgs
527M    os
91M     oss
3.4M    System
302M    thirdpartypkgs
8.4M    zookeeper

That's it. As simple as that.

I hope that this tip help you.

Regards
Mario

domingo, 9 de junho de 2024

[ORACLE] Redo log file status are CLEARING or CLEARING_CURRENT after Restore.

Hello everyone.

Did you have this problem after restore?


Ohhh my good! WTF?

The first command "alter database open resetlogs" is abnormally abrupted leaving the redo log file status as CLEARING or CLEARING_CURRENT in controlfile.

I'll show you:

SELECT
    l.INST_ID, 
    l.THREAD#, 
    l.GROUP#, 
    substr(lf.MEMBER,1,75) as MEMBER, 
    l.SEQUENCE#, 
    l.FIRST_CHANGE#, 
    l.BYTES/(1024 * 1024) AS "Size MB", 
    l.MEMBERS, l.ARCHIVED, 
    l.STATUS, 
    lf.IS_RECOVERY_DEST_FILE, 
    l.CON_ID
FROM gv$log l
JOIN gv$logfile lf ON 
            l.INST_ID = lf.INST_ID and 
    l.GROUP# = lf.GROUP#
ORDER BY 1,2,3;



The solution is simple, but always remember:
  • This step-by-step worked for me, but it may not work for you.
  • This post is for help you, but never take my word for it, test it well before use.

Execute the clear unarchived command:
    alter database clear unarchived logfile group 1;
    alter database clear unarchived logfile group 2;
    alter database clear unarchived logfile group 3;
    alter database open resetlogs;


Here you done!



Or, you can recreate a controlfile. If you want to know more about this solution, check the note ALTER DATABASE OPEN RESETLOGS fails with ORA-00392 (Doc ID 1352133.1).

A quick and simple tip, but one that helps a lot.

Regards
Mario










sexta-feira, 8 de março de 2024

[ORACLE] Batch change EDITIONABLE property.

Hello everyone.

Hope you're doing well!

Today, I have a simple case.
 
A test database had many database objects with the EDITIONABLE property set to "N".

Why did this happen? I have no idea!

Of course, you don't have any possibility to making the change manually, object by object.

This isn't a normal thing to happen, so... let's get to the solution.

A simple script solves the problem. 😆

But always remember:  
  • This step-by-step worked for me, but it may not work for you.
  • It's a test environment. The real life will be different, for sure.
  • This post is for study and testing as well and has no concern for performance and security best practices.

1) First, count the objects that will be changed.

SELECT
    substr(OWNER,1,20) AS OWNER,
    count(1) AS TOTAL,
    EDITIONABLE
FROM
    DBA_OBJECTS
WHERE
OWNER IN (
         'AUDIT_DBAMV','DBAADV','DBACP','DBADW','DBAMV',          
         'DBAPORTAL','DBAPS','DBASGU','DBATUALIZA','EDITOR','IDCE', 
         'MPACS','MVAPI','MVBIKE','MVINTEGRA','MVMOBILE','SITEDS')
AND 
OBJECT_TYPE IN (
         'FUNCTION','LIBRARY','PACKAGE BODY','PACKAGE',
         'PROCEDURE', 'TRIGGER','TYPE','TYPE BODY',
         'SYNONYM','VIEW')
AND 
EDITIONABLE = 'N'
GROUP BY OWNER, EDITIONABLE
ORDER BY OWNER, EDITIONABLE;



2) Generate the script for change.

SET SERVEROUTPUT ON;
SET PAGES 0;
SET VERIFY OFF;
SET FEEDBACK OFF;
SET HEADING  OFF;
     
SELECT 
   'ALTER '||object_type || ' ' || owner || '.' || object_name || ' EDITIONABLE;'
FROM
DBA_OBJECTS 
WHERE
OWNER IN (
         'AUDIT_DBAMV','DBAADV','DBACP','DBADW','DBAMV',          
         'DBAPORTAL','DBAPS','DBASGU','DBATUALIZA','EDITOR','IDCE', 
         'MPACS','MVAPI','MVBIKE','MVINTEGRA','MVMOBILE','SITEDS')
AND 
OBJECT_TYPE IN (
         'FUNCTION','LIBRARY','PACKAGE BODY','PACKAGE',
         'PROCEDURE', 'TRIGGER','TYPE','TYPE BODY',
         'SYNONYM','VIEW')
AND 
EDITIONABLE = 'N'
ORDER BY OWNER;

As simple as that.

But be careful. Some objects may be in heavy use at the moment, and because of this we can generate Library Cache Pin or Library Cache Lock waits - as in the image below. 
Therefore, it's important to run the script at a time when the database workload is low, monitoring the objects in use and the wait events.  



You can check the objects in the library cache using this SQL. This won't give you 100% certainty that the object is currently in use, but it's a good indicator.

SELECT 
     substr(OWNER,1,15) AS OWNER,
     substr(NAME,1,30)  AS NAME, 
     count(1) 
FROM
     GV$DB_OBJECT_CACHE 
WHERE
     NAME IN (
      'TRG_NOTA_FISCAL_CONV_PART','TRG_NOTA_FISCAL_FNFI',
      'TRG_NOTA_FISCAL_VALIDA_CNPJ','TRG_NOTA_FISCAL_PROIBE_CANC_NF',
      'TRG_NOTA_FISCAL_PARTICULAR','TRG_NOTA_FISCAL_AJUSTES',
      'TRG_NOTA_FISCAL_DADOS_NFE','TRG_NOTA_FISCAL_SN_CONTABILIZA',
      'TRG_EVOLUCAO_NOTA_FISCAL','TRG_FNFI_NF_INTEGRA_BENNER',
      'TRG_ATUALIZA_HIST_SIT_NF','TRG_STATUS_NFE_NOTA_FISCAL',
      'TRG_IMVW_OUT_NF_SUNAT')
GROUP BY OWNER, NAME;


3) Once again, count the objects with EDITIONABLE = N.



4) And count the objects with EDITIONABLE = Y.


I hope this simple tip helps you.

Regards
Mario





terça-feira, 23 de janeiro de 2024

[ORACLE] How to move a datafile to a new location in ASM.

Hello everyone!

I hope you're doing well!

Today, I needed to move a datafile to another ASM Disk Group.

The process was simple, but remember that this step-by-step worked for me, but it may not work for you.

So do it in a test environment if you're not sure.

Important:
  • For SYS and SYSAUX, the procedure will be slightly different, so don't use this step-by-step in these two cases. 
  • There are also other ways to do this process, today I chose to do this one.
So, let's go to the party!

1) Check the datafile path
    SQL> SELECT file#, name FROM v$datafile where name like '%zab%';


2) Create a backup as copy with RMAN
    RMAN> BACKUP AS COPY DATAFILE 69 format '+DGFRA';


3) I put the datafile offline
    SQL> ALTER DATABASE DATAFILE 69 offline;


4) I switch & recover the datafile
    RMAN> switch datafile 69 to copy;
    RMAN> recover datafile 69;



5) I put the datafile online
    SQL> ALTER DATABASE DATAFILE 69 online;


6) Check the datafile in the new location 
    SQL> SELECT file#, name FROM v$datafile where name like '%zab%';


7) Delete the old datafile
    RMAN> delete datafilecopy '+DGDATA/PRD/DATAFILE/tbs_zabbix.334.1144323691';


As simple as that!

Regards
Mario

Postagem em destaque

[ORACLE] Cleanup Repository Area - Oracle Database Appliance (ODA)

Hello everyone. How are you doing? Today, I'll share with you a simple tip about ODA. When I need to clean the repository area, I use th...