Blog
Monitoring Data Guard operation
Category: Database Author: Andre Luiz Dutra Ontalba (Board Member) Date: 6 years ago Comments: 0

Monitoring Data Guard operation

As we saw in the last article on installing DataGuard in Oracle 19C, we will now see how to monitor Data Guard.
 
 
— This script is to be run on the Standby of a Data Guard Physical Standby Site

 

set echo off
set feedback off
column timecol new_value tstamp
column spool_extension new_value suffix
select to_char(sysdate,'Mondd_hhmi') timecol from sys.dual;
column output new_value dbname
select value || '_' output from v$parameter where name = 'db_name';
— Output the results to this file
spool dg_Standby_diag_&&dbname&&tstamp
set lines 132
set pagesize 500
set numformat 999999999999999
set trim on
set trims on
— Get the current Date
set feedback on
select systimestamp from dual;

-- Standby Site Details
set heading off
set feedback off
select 'Standby Site Details' from dual;
select '********************' from dual;
set heading on
set feedback on

col db_unique_name format a15
col flashb_on format a10

select DB_UNIQUE_NAME,DATABASE_ROLE DB_ROLE,FORCE_LOGGING F_LOG,FLASHBACK_ON FLASHB_ON,LOG_MODE,OPEN_MODE,
GUARD_STATUS GUARD,PROTECTION_MODE PROT_MODE
from v$database;
— Current SCN – this value on the primary and standby sites where real time apply is in place should be nearly the same

 

select DB_UNIQUE_NAME,SWITCHOVER_STATUS,CURRENT_SCN from v$database;

-- Incarnation Information
--

set heading off
set feedback off
select 'Incarnation Destination Configuration' from dual;
select '*************************************' from dual;
set heading on
set feedback on

select INCARNATION# INC#, RESETLOGS_CHANGE# RS_CHANGE#, RESETLOGS_TIME, PRIOR_RESETLOGS_CHANGE# PRIOR_RS_CHANGE#, STATUS,FLASHBACK_DATABASE_ALLOWED FB_OK from v$database_incarnation;

set heading off
set feedback off
select 'Archive Destination Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on
-- Current Archive Locations
--

column host_name format a30 tru
column version format a10 tru
select INSTANCE_NAME,HOST_NAME,VERSION,ARCHIVER from v$instance;

column destination format a35 wrap
column process format a7
column archiver format a8
column dest_id format 99999999

select DEST_ID,DESTINATION,STATUS,TARGET,ARCHIVER,PROCESS,REGISTER,TRANSMIT_MODE
from v$archive_dest
where DESTINATION IS NOT NULL;

column name format a22
column value format a100
select NAME,VALUE from v$parameter where NAME like 'log_archive_dest%' and upper(VALUE) like 'SERVICE%';

set heading off
set feedback off
select 'Archive Destination Errors' from dual;
select '**************************' from dual;
set heading on
set feedback on

column error format a55 tru
select DEST_ID,STATUS,ERROR from v$archive_dest
where DESTINATION IS NOT NULL;

column message format a80
select MESSAGE, TIMESTAMP
from v$dataguard_status
where SEVERITY in ('Error','Fatal')
order by TIMESTAMP;

-- Redo Log configuration
-- The size of the standby redo logs must match exactly the size on the online redo logs

set heading off
set feedback off
select 'Data Guard Redo Log Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on

select GROUP# STANDBY_GROUP#,THREAD#,SEQUENCE#,BYTES,USED,ARCHIVED,STATUS from v$standby_log order by GROUP#,THREAD#;

select GROUP# ONLINE_GROUP#,THREAD#,SEQUENCE#,BYTES,ARCHIVED,STATUS from v$log order by GROUP#,THREAD#;
— Data Guard Parameters

set heading off
set feedback off
select 'Data Guard Related Parameters' from dual;
select '*****************************' from dual;
set heading on
set feedback on

column name format a30
column value format a100
select NAME,VALUE from v$parameter where NAME IN ('db_unique_name','cluster_database','dg_broker_start','dg_broker_config_file1','dg_broker_config_file2','fal_client','fal_server','log_archive_config','log_archive_trace','log_archive_max_processes','archive_lag_target','remote_login_password_file','redo_transport_user') order by name;
— Managed Recovery State

 

set heading off
set feedback off
select 'Data Guard Apply Status' from dual;
select '***********************' from dual;
set heading on
set feedback on

select systimestamp from dual;

column client_pid format a10
select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

set heading off
set feedback off
select 'Data Guard Apply Lag' from dual;
select '********************' from dual;
set heading on
set feedback on

column name format a12
column lag_time format a20
column datum_time format a20
column time_computed format a20
SELECT NAME, VALUE LAG_TIME, DATUM_TIME, TIME_COMPUTED
from V$DATAGUARD_STATS where name like 'apply lag';
— If there is a lag remove the comment for the select below

 

-- SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' AND COUNT > 0;

set heading off
set feedback off
select 'Data Guard Gap Problems' from dual;
select '***********************' from dual;
set heading on
set feedback on

select * from v$archive_gap;

set heading off
set feedback off
select 'Data Guard Errors in the Last Hour' from dual;
select '**********************************' from dual;
set heading on
set feedback on

select TIMESTAMP,SEVERITY,ERROR_CODE,MESSAGE from v$dataguard_status where timestamp > systimestamp-1/24;
spool off

 



Hope this helps. See you !!!
 
André  Ontalba  – www.dbadutra.com
 
 
 
 
 
 

 Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

 


New Feature in Autonomous Database – Auto Scaling
Category: Cloud Author: Andre Luiz Dutra Ontalba (Board Member) Date: 6 years ago Comments: 0

New Feature in Autonomous Database - Auto Scaling

 
Yesterday a new feature was released in the Autonomous Database.
 
The Auto Scaling feature, you can select auto scaling during provisioning or later using the Scale Up/Down button on the Oracle Cloud Infrastructure console.
 
When you select auto scaling Autonomous Data Warehouse can use up to three times more CPU and IO resources than specified by the number of OCPUs currently shown in the Scale Up/Down dialog. 
 
When auto scaling is enabled, if your workload requires additional CPU and IO resources the database automatically uses the resources without any manual intervention required.
 
To see the average number of OCPUs used during an hour you can use the “Number of OCPUs allocated” graph on the Overview page on the Autonomous Data Warehouse service console.
 
Enabling auto scaling does not change the concurrency and parallelism settings for the predefined services.
 
Hope this helps. See you !!!
 
André  Ontalba  – www.dbadutra.com
 
 
 
 
 
 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”


Query the last patch applied on database 11g, 12cR1, 12cR2 and 18c
Category: Database Author: Rodrigo Mufalani (Board Member) Date: 6 years ago Comments: 0

Query the last patch applied on database 11g, 12cR1, 12cR2 and 18c

 
 
Part of DBA routine is patch databases by quarterly, what is that means? 
 
It means that Oracle is a software and it is hard to hear, but Oracle database has bugs and secutiry vulnerabilities, so is good idea patch regularly your production databases with RU and RUR, you can
find more information about this change on nomenclature that occurred on 12cR2 at this of link on blog of the master https://mikedietrichde.com/2017/11/07/ru-rur-recommendations-facts/
So, usually a patch came with 2 different parts, first part is the binaries (libraries, programs and etc), you must be familiar with opatch utility to apply a patch on the Oracle Home, and the second part is the data dictionary corrections. 
To execute this part, since Oracle version 12cR1 we use datapatch to apply, this tool is amazing, really like to use it. So, the datapatch utility, is part of OPatch and the purpose of usage of this tool is apply scripts against Oracle data dictionary.
In this article I will show to you, how to query the correct views on the database to find informations about 11g, and 12c (family) databases, let’s say like that.
 
So, on version 11g, after apply a PSU patch on database, after run the script catbundle.sql, you can query this view with SYS account, to check information about the past PSUs applied:

— 11g version

set lin 1000
col action form a12
col version form a40
col comments form a70
col action_date form a20

select comments, action, to_char(action_time,’DD/MM/RR HH24:MI:SS’) action_date, version
from registry$history
order by action_date;

COMMENTS ACTION ACTION_DATE VERSION
———————————————————————- ———— ——————– —————————————-
Patch applied from 18.1.0.0.0 to 18.3.0.0.0 RU_APPLY 20/03/19 14:36:26 18.0.0.0.0
OJVM RU post-install APPLY 20/03/19 14:37:42 18.3.0.0.180717OJVMRU
RAN jvmpsu.sql jvmpsu.sql 20/03/19 14:37:42 18.3.0.0.180717OJVMRU
RDBMS_18.3.0.0.0DBRU_LINUX.X64_180627 BOOTSTRAP 18

 

For the version 12R1 and onwards you will need to use another view and depending against wich version are running you can filter by PSU ou RELEASE words on column description:
 

— For 12c and 18c
set lin 1000
col action form a12
col version form a40
col description form a85
col action_date form a20

select description, action, to_char(action_time,’DD/MM/RR HH24:MI:SS’) action_date, ‘ ‘ version
from dba_registry_sqlpatch;

DESCRIPTION ACTION ACTION_DATE VERSION
————————————————————————————- ———— ——————– —————————————-
Database Release Update : 18.3.0.0.180717 (28090523) APPLY 20/03/19 14:37:46
OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415) APPLY 20/03/19 14:37:46

 

Obs.: There is no more version column, I keep that just for have compatibility with some old scripts.
 

To query:
— 12cR1
where upper(description) like ‘DATABASE PSU%’;

— 12cR2 onwards
where upper(descrition) like ‘DATABASE RELEASE%’;

 

I hope this brief note can help you to find more details how to query and check if the version applied on binaries matches the version of the database level of patch.
 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

All the best,
Rodrigo Mufalani

ODA, JSON and Flash
Category: Engineer System Author: Fernando Simon (Board Member) Date: 6 years ago Comments: 0

ODA, JSON and Flash

Recently, in March, I made the reimage from an X5-2 HA ODA and saw a strange behavior during the diskgroup creation and couldn’t reproduce (because involve reimaging again). Basically, the FLASH diskgroup was not created.
But in last May I reimaged another ODA using the same patch/imageversion (18.3.0.0 – Patch 27604623) and was possible to verify again. In both cases, I created the appliance using the CLI “odacli create-appliance” using JSON file because the network uses VLAN (what it is impossible to create using the web interface), and both appliances are identical (X5-2 HA with SSD for RECO and FLASH).
To reimage, I followed the steps in the docs for this version and used the ISO to do the baremetal procedure. If you look in the docs about the options for storage (check here) you can see that there is no single reference to use FLASH diskgroup (or that you need to do that). Checking in the readme/reference JSON files that exist in the folder “/opt/oracle/dcs/sample” under file “sample-oda-ha-json-readme.txt”:grid:
 

    diskGroup: (ODA HA contains DATA, RECO and REDO Diskgroups)

        diskgroupName: DATA|RECO|REDO

        redundancy: Normal|High

            If the system has less than 5 NVMe storage devices, redundancy is Normal.

            If the system has 5 or more NVMes, then Normal or High are supported.

        diskPercentage: Percentage of NVMe drive capacity is used for this particular diskgroup.

 

And the example that come with image (sample-oda-ha.json):

  “grid” : {

    “diskGroup” : [ {

      “diskGroupName” : “DATA”,

      “redundancy” : “”,

      “diskPercentage” :80

    }, {

      “diskGroupName” : “RECO”,

      “redundancy” : “”,

      “diskPercentage” :20

    }, {

      “diskGroupName”: “REDO”,

      “diskPercentage”: 100,

      “redundancy”: “HIGH”

    } ],

 
As you can see there is no reference to FLASH, or even if it is possible to use that (because the options are diskgroupName: DATA|RECO|REDO). Based on that (and supposing that FLASH will be created automatically – since X5-2 have these SSD disk dedicated to that) I made JSON file with:

  “grid” : {

    “diskGroup” : [ {

      “diskGroupName” : “DATA”,

      “redundancy” : “NORMAL”,

      “disks” : null,

      “diskPercentage” : 90

    }, {

      “diskGroupName” : “RECO”,

      “redundancy” : “NORMAL”,

      “disks” : null,

      “diskPercentage” : 10

    }, {

      “diskGroupName” : “REDO”,

      “redundancy” : “HIGH”,

      “disks” : null,

      “diskPercentage” : null

    } ],

 

And after the create-appliance command I got just these filegroups in ASM:

ASMCMD> lsdg

State    Type    Rebal  Sector  Logical_Sector  Block       AU   Total_MB    Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name

MOUNTED  NORMAL  N         512             512   4096  4194304  108019712  108000740          6751232        50624754              0             Y  DATA/

MOUNTED  NORMAL  N         512             512   4096  4194304   11997184   11995456           749824         5622816              0             N  RECO/

MOUNTED  HIGH    N         512             512   4096  4194304     762880     749908           190720          186396              0             N  REDO/

ASMCMD>

 

And the describe-system reports:

[root@ODA1 ~]# /opt/oracle/dcs/bin/odacli describe-system

 

Appliance Information

—————————————————————-

                     ID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

               Platform: X5-2-HA

        Data Disk Count: 24

         CPU Core Count: 6

                Created: March 26, 2019 11:56:24 AM CET

 

System Information

—————————————————————-

                   Name: ODA

            Domain Name: XYZ.XYZ

              Time Zone: Europe/Luxembourg

             DB Edition: EE

            DNS Servers: 1.1.1.1 2.2.2.2

            NTP Servers: 3.3.3.3

 

Disk Group Information

—————————————————————-

DG Name                   Redundancy                Percentage

————————- ————————- ————

Data                      Normal                    90

Reco                      Normal                    10

Redo                      High                      100

 

[root@ODA1 ~]#

 

After that, the only option was creating the FLASH manually:

SQL> create diskgroup FLASH normal redundancy

  2     DISK ‘AFD:SSD_E0_S16_1320409344P1’ NAME SSD_E0_S16_1320409344P1

  3     ,  ‘AFD:SSD_E0_S17_1320408816P1’ NAME SSD_E0_S17_1320408816P1

  4     ,  ‘AFD:SSD_E0_S18_1320404784P1’ NAME SSD_E0_S18_1320404784P1

  5     ,  ‘AFD:SSD_E0_S19_1320406740P1’ NAME SSD_E0_S19_1320406740P1

  6     attribute  ‘COMPATIBLE.ASM’ =   ‘18.0.0.0.0’

  7     , ‘COMPATIBLE.rdbms’ = ‘12.1.0.2’

  8     , ‘compatible.advm’ = ‘18.0.0.0’

  9     , ‘au_size’=’4M’

  10  ;

 

Diskgroup created.

 

SQL> select NAME, SECTOR_SIZE, ALLOCATION_UNIT_SIZE, COMPATIBILITY, DATABASE_COMPATIBILITY from v$asm_diskgroup;

 

NAME                           SECTOR_SIZE ALLOCATION_UNIT_SIZE COMPATIBILITY                                                DATABASE_COMPATIBILITY

—————————— ———– ——————– ———————————————————— ————————————————————

DATA                                   512              4194304 18.0.0.0.0                                                   12.1.0.2.0

RECO                                   512              4194304 18.0.0.0.0                                                   12.1.0.2.0

REDO                                   512              4194304 18.0.0.0.0                                                   12.1.0.2.0

FLASH                                  512              4194304 18.0.0.0.0                                                   12.1.0.2.0

 

SQL>

Reimage again, or cleanup everything, sometimes it is not an option. Change the JSON file and modify the parameter “dbOnFlashStorage” it is not correct since will fail again as you can see in the release notes for version 12.2.1.3.0 that says in workaround: “Provide information for DATA, REDO, RECO, and FLASH disk groups at the time of provisioning. If you have provisioned your environment without creating the FLASH disk group, then create the FLASH disk group manually. This issue is tracked with Oracle bug 27721310.
 
Second try
For the second reimage I specified my JSON file as:

  “grid” : {

    “diskGroup” : [ {

      “diskGroupName” : “DATA”,

      “redundancy” : “NORMAL”,

      “disks” : null,

      “diskPercentage” : 90

    }, {

      “diskGroupName” : “RECO”,

      “redundancy” : “NORMAL”,

      “disks” : null,

      “diskPercentage” : 10

    }, {

      “diskGroupName” : “REDO”,

      “redundancy” : “HIGH”,

      “disks” : null,

      “diskPercentage” : null

    }, {

      “diskGroupName” : “FLASH”,

      “redundancy” : “NORMAL”,

      “disks” : null,

      “diskPercentage” : null

    } ],

 

And the describe for system now says:

[root@OAK1 ~]# /opt/oracle/dcs/bin/odacli describe-system

 

Appliance Information

—————————————————————-

                     ID: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

               Platform: X5-2-HA

        Data Disk Count: 24

         CPU Core Count: 36

                Created: May 22, 2019 11:03:36 AM CEST

 

System Information

—————————————————————-

                   Name: OAK

            Domain Name: XYZ.XYZ

              Time Zone: Europe/Luxembourg

             DB Edition: EE

            DNS Servers: 1.1.1.1 2.2.2.2

            NTP Servers: 3.3.3.3

 

Disk Group Information

—————————————————————-

DG Name                   Redundancy                Percentage

————————- ————————- ————

Data                      Normal                    90

Reco                      Normal                    10

Redo                      High                      100

Flash                     Normal                    100

 

[root@OAK1 ~]#

And I can confirm everything as expected in ASM:

ASMCMD> lsdg

State    Type    Rebal  Sector  Logical_Sector  Block       AU   Total_MB    Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name

MOUNTED  NORMAL  N         512             512   4096  4194304  108019712  108007188          6751232        50627978              0             Y  DATA/

MOUNTED  NORMAL  N         512             512   4096  4194304    1525760    1518672           381440          568616              0             N  FLASH/

MOUNTED  NORMAL  N         512             512   4096  4194304   11997184   11995736           749824         5622956              0             N  RECO/

MOUNTED  HIGH    N         512             512   4096  4194304     762880     749908           190720          186396              0             N  REDO/

ASMCMD>

If you compare the job report for the new create-appliance execution:

Post cluster OAKD configuration          May 22, 2019 11:53:45 AM CEST       May 22, 2019 11:59:11 AM CEST       Success

Disk group ‘RECO’creation                May 22, 2019 11:59:20 AM CEST       May 22, 2019 11:59:38 AM CEST       Success

Disk group ‘REDO’creation                May 22, 2019 11:59:38 AM CEST       May 22, 2019 11:59:47 AM CEST       Success

Disk group ‘FLASH’creation               May 22, 2019 11:59:47 AM CEST       May 22, 2019 11:59:58 AM CEST       Success

Volume ‘commonstore’creation             May 22, 2019 11:59:58 AM CEST       May 22, 2019 12:00:48 PM CEST       Success

It is different from the previous:

Post cluster OAKD configuration          March 26, 2019 1:47:06 PM CET       March 26, 2019 1:52:32 PM CET       Success

Disk group ‘RECO’creation                March 26, 2019 1:52:41 PM CET       March 26, 2019 1:52:57 PM CET       Success

Disk group ‘REDO’creation                March 26, 2019 1:52:57 PM CET       March 26, 2019 1:53:07 PM CET       Success

Volume ‘commonstore’creation             March 26, 2019 1:53:07 PM CET       March 26, 2019 1:53:53 PM CET       Success

 

Know your environment and your target
So, be careful during your ODA deployment, even if the doc says something, check again to avoid errors. It is important to know your environment and be aware of what is expected as a result. Here in this case, even if the docs says nothing about specifying the FLASH diskgroup, it is needed and if you forgot, not FLASH for you.
 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

 

 

Fernando Simon – http://www.fernandosimon.com/blog

1 27 28 29 30 31 32