Thinking Out Loud

February 19, 2018

How Do You Create Data Guard Configuration?

Filed under: 12c,Dataguard,dgmgrl — mdinh @ 11:30 pm

I have taken for granted to create Data Guard Configuration the same way most of the time that I don’t know what goes wrong when done differently.

oracle@racnode-dc1-1:hawk1:/home/oracle
$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Mon Feb 19 23:41:49 2018

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options

23:41:49 SYS @ hawk1:>show parameter db%name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert                 string
db_name                              string      hawk
db_unique_name                       string      hawk
pdb_file_name_convert                string

23:42:04 SYS @ hawk1:>alter system set dg_broker_start=true sid='*' scope=memory;

System altered.

23:42:40 SYS @ hawk1:>


+++ CREATE CONFIGURATION USING UPPER CASE WITHOUT QUOTES

oracle@racnode-dc1-1:hawk1:/home/oracle
$ dgmgrl /
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDG.

--- NO QUOTES USE AND ALL UPPERCASE - EASIEST METHOD
--- Broker convert database to match that of db_unique_name

DGMGRL> CREATE CONFIGURATION DG_CONFIG AS PRIMARY DATABASE IS HAWK CONNECT IDENTIFIER IS HAWK;
Configuration "dg_config" created with primary database "hawk"

DGMGRL> show configuration

Configuration - dg_config

  Protection Mode: MaxPerformance
  Members:
  hawk - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

DGMGRL> show database hawk

Database - hawk

  Role:               PRIMARY
  Intended State:     OFFLINE
  Instance(s):
    hawk1
    hawk2

Database Status:
DISABLED

DGMGRL> remove configuration
Removed configuration

--- CONFIGURATION IS UPPERCASE 
--- Does it look better in uppercase?
DGMGRL> CREATE CONFIGURATION 'DG_CONFIG' AS PRIMARY DATABASE IS 'hawk' CONNECT IDENTIFIER IS HAWK;
Configuration "DG_CONFIG" created with primary database "hawk"
DGMGRL> show configuration

Configuration - DG_CONFIG

  Protection Mode: MaxPerformance
  Members:
  hawk - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

DGMGRL> show database hawk

Database - hawk

  Role:               PRIMARY
  Intended State:     OFFLINE
  Instance(s):
    hawk1
    hawk2

Database Status:
DISABLED

DGMGRL> remove configuration
Removed configuration

+++ ISSUES OCCUR WHEN USING UPPERCASE WITH QUOTES FOR DATABASE
+++ Not sure if this will work as I have not tested end to end. Why create it this way to begin with?
DGMGRL> CREATE CONFIGURATION 'DG_CONFIG' AS PRIMARY DATABASE IS 'HAWK' CONNECT IDENTIFIER IS HAWK;
Configuration "DG_CONFIG" created with primary database "HAWK"
DGMGRL> show configuration

Configuration - DG_CONFIG

  Protection Mode: MaxPerformance
  Members:
  HAWK - Primary database

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

DGMGRL> show database hawk
Object "hawk" was not found

DGMGRL> show database HAWK
Object "hawk" was not found

DGMGRL> show database 'HAWK';

Database - HAWK

  Role:               PRIMARY
  Intended State:     OFFLINE
  Instance(s):
    hawk1
    hawk2

Database Status:
DISABLED

DGMGRL>

REFERENCE:

CREATE CONFIGURATION

CREATE CONFIGURATION configuration_name AS PRIMARY DATABASE IS database-name CONNECT IDENTIFIER IS connect-identifier;

database-name
The name that will be used by the broker to refer to the primary database. 
It must match (case-insensitive) the value of the primary database DB_UNIQUE_NAME initialization parameter.
Advertisements

February 15, 2018

12c DataGuard / Broker Pitfalls

Filed under: 12c,Dataguard — mdinh @ 1:01 pm

In a broker configuration, you use the DGConnectIdentifer property to specify a connect identifier for each database.

The connect identifier for a database must:
Allow all other databases in the configuration to reach it.
Allow all instances of an Oracle RAC database to be reached.
Specify a service that all instances dynamically register with the listeners so that connect-time failover on an Oracle RAC database is possible.

The service should NOT be one that is defined and managed by Oracle Clusterware.

A static service needs to be defined and registered only if Oracle Clusterware or Oracle Restart is not being used.

Else, by default, the broker assumes a static service name of db_unique_name_DGMGRL.db_domain and expects the listener has been started with the following content in the listener.ora file:

LISTENER =
(DESCRIPTION_LIST =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
  )
)

SID_LIST_LISTENER=
(SID_LIST=
  (SID_DESC=
    (GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
    (ORACLE_HOME=oracle_home)
    (SID_NAME=sid_name)
    (ENVS="TNS_ADMIN=oracle_home/network/admin")
  )
)  

As of Oracle Database 12c Release 1 (12.1), for all databases to be added to a broker configuration, any LOG_ARCHIVE_DEST_n parameters that have the SERVICE attribute set, but not the NOREGISTER attribute, must be cleared.

Create Configuration Failing with ORA-16698 (Doc ID 1582179.1)

Oracle Data Guard Installation

 

February 11, 2018

Goldengate REPORTING

Filed under: GoldenGate — mdinh @ 2:52 pm

There were performance issues due to a new table being introduced to replication and I was asked to gather number of DMLs on table for 1 day.

Using DBA_TAB_MODIFICATIONS did not meet the requirements since statistics were gather about a week ago and over inflated.

Next thought process was why not use Goldengate since it captures all the changes and report on it.

This may or may not provide the required data if reporting is not properly configured.

Some will tell you to never rollover the report while others will rollover the report on a weekly basis.

From most recent experience, I would rollover report on daily basis because data can always be aggregated.

Here is an example of what I had to deal with.

$ grep -i report dirprm/e_hawk.prm

REPORTCOUNT EVERY 10 MINUTES, RATE

$ grep “activity since” dirtpt/E*.rpt|sort

E_HAWK0.rpt:Report at 2018-02-09 12:28:49 (activity since 2018-02-08 22:01:15)
--- How are you going to get daily activities accurately from aggregation over 2 months time frame?
E_HAWK1.rpt:Report at 2018-02-08 21:48:37 (activity since 2017-11-27 18:24:26)

Corresponding data from the report.
$ grep -A5 “From Table SCOTT.RATETEST” dirrpt/E_*rpt

E_HAWK0.rpt:Report at 2018-02-09 12:28:49 (activity since 2018-02-08 22:01:15)
dirrpt/E_HAWK0.rpt:From Table SCOTT.RATETEST:
dirrpt/E_HAWK0.rpt-       #                   inserts:       977
dirrpt/E_HAWK0.rpt-       #                   updates:  10439912
dirrpt/E_HAWK0.rpt-       #                   befores:  10439912
dirrpt/E_HAWK0.rpt-       #                   deletes:         0
dirrpt/E_HAWK0.rpt-       #                  discards:         0
--
E_HAWK1.rpt:Report at 2018-02-08 21:48:37 (activity since 2017-11-27 18:24:26)
dirrpt/E_HAWK1.rpt:From Table SCOTT.RATETEST:
dirrpt/E_HAWK1.rpt-       #                   inserts:     87063
dirrpt/E_HAWK1.rpt-       #                   updates: 821912582
dirrpt/E_HAWK1.rpt-       #                   befores: 821912582
dirrpt/E_HAWK1.rpt-       #                   deletes:         0
dirrpt/E_HAWK1.rpt-       #                  discards:         0

How did I end up getting the data?

From Goldengate report above (E_HAWK0.rpt) which is better as it provides the exact data processed by Goldengate vs trying to extract data from database.

I was lucky! Extract was restarted when table was added and removed.

Example of Better Configuration:

global_ggenv.inc

STATOPTIONS RESETREPORTSTATS
REPORT AT 00:01
REPORTROLLOVER AT 00:01
REPORTCOUNT EVERY 60 MINUTES, RATE
DISCARDROLLOVER AT 00:01

e_hawk.prm
EXTRACT E_HAWK

EXTRACT e_hawk
EXTTRAIL ./dirdat/bb
-- CHECKPARAMS
INCLUDE ./dirprm/global_macro.inc
INCLUDE ./dirprm/global_dbenv.inc
INCLUDE ./dirprm/global_ggenv.inc

Reference:

REPORTROLLOVER

Use the REPORTROLLOVER parameter to force report files to age on a regular schedule, instead of when a process starts. 
For long or continuous runs, setting an aging schedule controls the size of the active report file and provides a more predictable set of archives that can be included in your archiving routine.
Report statistics are carried over from one report to the other. To reset the statistics in the new report, use the STATOPTIONS parameter with the RESETREPORTSTATS option.

DBA_TAB_MODIFICATIONS

INSERTS/UPDATES/DELETES - Approximate number since the last time statistics were gathered.

February 3, 2018

PURGEOLDEXTRACTS Not Purging Trail Files Part2

Filed under: 12c,GoldenGate — mdinh @ 4:55 pm
If you read the post PURGEOLDEXTRACTS Not Purging Trail Files, you will find the solution is to replace syntax from mgr.prm as shown below:
Replace PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPDAYS 1
With    PURGEOLDEXTRACTS /ggs/dirdat/*, USECHECKPOINTS, MINKEEPDAYS 2 

I found the solution by luck vs correct analysis; hence, the adage “Better to be lucky than good.”

Recently, the same issue occurred again for another environment and the solution was just the opposite.

PURGEOLDEXTRACTS dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24, FREQUENCYMINUTES 30
-- PURGEOLDEXTRACTS /DBFS/ggs/dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24, FREQUENCYMINUTES 30

Why is that!

No convention and inconsistency.

Here are the details.

--- How is manager configured?
GGSCI> send manager GETPURGEOLDEXTRACTS

Sending GETPURGEOLDEXTRACTS request to MANAGER ...

--- Manager is configured with trail pointing to /DBFS
PurgeOldExtracts Rules
Fileset                              MinHours MaxHours MinFiles MaxFiles UseCP
/DBFS/ggs/dirdat/*                   24       0        1        0        Y
OK	
--- Extract trail showing from $GG_HOME/dirdat
Extract Trails
Filename                        Oldest_Chkpt_Seqno  IsTable  IsVamTwoPhaseCommit
/u01/app/gg/12.2.0/dirdat/aa    16285

--- How was the extract created?
GGSCI> send e* status

Sending STATUS request to EXTRACT E_HAWK ...


EXTRACT E_HAWK (PID 40932)
  Current status: Recovery complete: At EOF

  Current read position:
  Sequence #: 16285
  RBA: 27233729
  Timestamp: 2018-01-25 21:01:35.000450
  Extract Trail: dirdat/aa --- This is how the trail is defined when extract was created

GGSCI> info e*

EXTRACT    E_HAWK    Last Started 2018-01-25 21:22   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:00 ago)
Process ID           40932
Log Read Checkpoint  File dirdat/aa000016286
                     2018-02-01 14:42:29.000124  RBA 29233729
GGSCI> exit

--- From $GG_HOME, dirdat is using symbolic link to /DBFS
$ ls -ld dir*
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirchk -> /DBFS/ggs/dirchk
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dircrd -> /DBFS/ggs/dircrd
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdat -> /DBFS/ggs/dirdat
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdef -> /DBFS/ggs/dirdef
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdmp -> /DBFS/ggs/dirdmp
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirout -> /DBFS/ggs/dirout
drwxr-xr-x 2 ggsuser oinstall 4096 Jan 26 13:49 dirpcs
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirprm -> /DBFS/ggs/dirprm
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirrpt -> /DBFS/ggs/dirrpt
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirsql -> /DBFS/ggs/dirsql
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirtmp -> /DBFS/ggs/dirtmp
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirwlt -> /DBFS/ggs/dirwlt
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirwww -> /DBFS/ggs/dirwww

In conclusion, PURGEOLDEXTRACTS location should be defined the same as the extract.

Isn’t that intuitive?

Oracle should make this a MOS Doc ;=)

January 31, 2018

Goldengate Tracing Network Ports

Filed under: GoldenGate — mdinh @ 4:30 am
--- Find mgr process
$ ps -ef|grep ./mgr
ggs  11823     1  0  2017 ?        00:29:13 ./mgr PARAMFILE /u01/app/ggs/dirprm/mgr.prm REPORTFILE /u01/app/ggs/dirrpt/MGR.rpt PROCESSID MGR
ggs  45054 30127  0 14:15 pts/0    00:00:00 grep --color=auto ./mgr

--- Find extract process
$ ps -ef|grep ./extract
ggs  17604 30127  0 14:15 pts/0    00:00:00 grep --color=auto ./extract
ggs  44306 11823  0 03:33 ?        00:01:28 /u01/app/ggs/extract PARAMFILE /u01/app/ggs/dirprm/e_hawk.prm REPORTFILE /u01/app/ggs/dirrpt/e_hawk.rpt PROCESSID e_hawk
ggs  44354 11823  0 03:33 ?        00:00:48 /u01/app/ggs/extract PARAMFILE /u01/app/ggs/dirprm/p_hawk.prm REPORTFILE /u01/app/ggs/dirrpt/p_hawk.rpt PROCESSID p_hawk

--- Find mgr port
$ lsof -i -P |grep 11823
mgr     11823 ggs    6u  IPv4 3492119103      0t0  TCP *:7809 (LISTEN)

--- Find extract port
$ lsof -i -P |grep 44306
extract 44306 ggs    6u  IPv4 2827659844      0t0  TCP *:7840 (LISTEN)

$ lsof -i -P |grep 44354
extract 44354 ggs    6u  IPv4 2827649786      0t0  TCP *:7841 (LISTEN)
extract 44354 ggs   10u  IPv4 2827610899      0t0  TCP hawk.local:21252->eagle.local:7822 (ESTABLISHED)

--- Use Goldengate to find the same info. However, it does only provides local port.
$ ./ggsci 

Oracle GoldenGate Command Interpreter for Oracle
Version 12.3.0.1.0 OGGCORE_12.3.0.1.0_PLATFORMS_170721.0154_FBO
Linux, x64, 64bit (optimized), Oracle 12c on Jul 21 2017 23:31:13
Operating system character set identified as UTF-8.

Copyright (C) 1995, 2017, Oracle and/or its affiliates. All rights reserved.

GGSCI> send manager childstatus debug

Sending CHILDSTATUS request to MANAGER ...

Child Process Status - 2 Entries

ID      Group   Process Retry Retry Time          Start Time          Port
---- -------- --------- ----- ------------------- ------------------- ----
   0   e_hawk     44306     0 None                2017/11/20 19:49:14 7840
   1   p_hawk     44354     0 None                2017/11/20 19:55:43 7841

GGSCI>

January 21, 2018

Be Friend With awk/sed | ASM Mapping

Filed under: 12c,ASM,awk_sed_grep — mdinh @ 5:10 pm

I had request to add disks to ASM Disk Group without any further details for what new disks were added.

Need to figure out which disks are on ASM now, which disks should be used as new ones.

Got lazy and created scripts for this for future use.

[root@racnode-dc1-1 ~]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks:               [  OK  ]
[root@racnode-dc1-1 ~]#

[oracle@racnode-dc1-1 ~]$ /etc/init.d/oracleasm listdisks
CRS01
DATA01
FRA01

--- [8,49] is major,minor for device
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01
Disk "DATA01" is a valid ASM disk on device [8,49]

--- Extract major,minor for devide
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01|awk '{print $NF}'
[8,49]

--- Remove [] brackets
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01|awk '{print $NF}'|sed s'/.$//'
[8,49
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01|awk '{print $NF}'|sed s'/.$//'|sed '1s/^.//'
8,49

--- Alternative option to remove []
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01|awk '{print $NF}'|sed 's/[][]//g'
8,49

--- Create patterns for grep
[oracle@racnode-dc1-1 ~]$ oracleasm querydisk -d DATA01|awk '{print $NF}'|sed s'/.$//'|sed '1s/^.//'|awk -F, '{print $1 ",.*" $2}'
8,.*49

--- Test grep using pattern
[oracle@racnode-dc1-1 ~]$ ls -l /dev/* | grep -E '8,.*49'
brw-rw---- 1 root    disk      8,  49 Jan 21 16:42 /dev/sdd1
[oracle@racnode-dc1-1 ~]$

--- Test grep with command line syntax
[oracle@racnode-dc1-1 ~]$ ls -l /dev/*|grep -E `oracleasm querydisk -d DATA01|awk '{print $NF}'|sed s'/.$//'|sed '1s/^.//'|awk -F, '{print $1 ",.*" $2}'`
brw-rw---- 1 root    disk      8,  49 Jan 21 16:42 /dev/sdd1
[oracle@racnode-dc1-1 ~]$

--- Run script
[oracle@racnode-dc1-1 ~]$ /sf_working/scripts/asm_mapping.sh
Disk "CRS01" is a valid ASM disk on device [8,33]
brw-rw---- 1 root    disk      8,  33 Jan 21 21:42 /dev/sdc1

Disk "DATA01" is a valid ASM disk on device [8,49]
brw-rw---- 1 root    disk      8,  49 Jan 21 21:42 /dev/sdd1

Disk "FRA01" is a valid ASM disk on device [8,65]
brw-rw---- 1 root    disk      8,  65 Jan 21 21:42 /dev/sde1

[oracle@racnode-dc1-1 ~]$

--- ASM Lib version
[oracle@racnode-dc1-1 ~]$ rpm -qa|grep asm
oracleasmlib-2.0.4-1.el6.x86_64
oracleasm-support-2.1.8-3.1.el7.x86_64
kmod-oracleasm-2.0.8-19.0.1.el7.x86_64
[oracle@racnode-dc1-1 ~]$

--- Script
[oracle@racnode-dc1-1 ~]$ cat /sf_working/scripts/asm_mapping.sh

#!/bin/sh -e
for disk in `/etc/init.d/oracleasm listdisks`
do
oracleasm querydisk -d $disk
#ls -l /dev/*|grep -E `oracleasm querydisk -d $disk|awk '{print $NF}'|sed s'/.$//'|sed '1s/^.//'|awk -F, '{print $1 ",.*" $2}'`
# Alternate option to remove []
ls -l /dev/*|grep -E `oracleasm querydisk -d $disk|awk '{print $NF}'|sed 's/[][]//g'|awk -F, '{print $1 ",.*" $2}'`
echo
done
[root@racnode-dc1-1 ~]# fdisk -l /dev/sdd1

Disk /dev/sdd1: 8587 MB, 8587837440 bytes, 16773120 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@racnode-dc1-1 ~]#

January 5, 2018

More Fun With sed

Filed under: awk_sed_grep — mdinh @ 2:33 am

Objective is to convert what looks to be Samba share from Windows to Linux current directory path.

Basically, the core of the code using sed.


sed -i.bak -e 's|C\:\\\\scripts|'"$PWD"'|g' -e 's|\\\\|\/|g' "$f"

[vagrant@db-asm-1 ~]$ pwd
/home/vagrant
[vagrant@db-asm-1 ~]$

[vagrant@db-asm-1 ~]$ ll
total 8
-rw-rw-r-- 1 vagrant vagrant 56 Jan  5 03:22 t.1
-rw-rw-r-- 1 vagrant vagrant 55 Jan  5 03:22 t.2
drwxrwxr-x 3 vagrant vagrant 18 Jan  5 03:21 working

[vagrant@db-asm-1 ~]$ cat t.1
set file_path "C:\\scripts"
source "$file_path\\t1.sql"

[vagrant@db-asm-1 ~]$ cat t.2
set file_path "C:\\scripts"
source "$file_path\\t2.sql


[vagrant@db-asm-1 ~]$ cat ~/working/dinh/test.sh
#!/bin/bash -ex
# Make sure you always put $f in double quotes to avoid any nasty surprises i.e. "$f"
for f in t.*
do
  echo "Processing $f file..."
  sed -i.bak -e 's|C\:\\\\scripts|'"$PWD"'|g' -e 's|\\\\|\/|g' "$f"
done


[vagrant@db-asm-1 ~]$ ~/working/dinh/test.sh
+ for f in 't.*'
+ echo 'Processing t.1 file...'
Processing t.1 file...
+ sed -i.bak -e 's|C\:\\\\scripts|/home/vagrant|g' -e 's|\\\\|\/|g' t.1
+ for f in 't.*'
+ echo 'Processing t.2 file...'
Processing t.2 file...
+ sed -i.bak -e 's|C\:\\\\scripts|/home/vagrant|g' -e 's|\\\\|\/|g' t.2


[vagrant@db-asm-1 ~]$ cat t.1
set file_path "/home/vagrant"
source "$file_path/t1.sql"

[vagrant@db-asm-1 ~]$ cat t.1.bak
set file_path "C:\\scripts"
source "$file_path\\t1.sql"


[vagrant@db-asm-1 ~]$ cat t.2
set file_path "/home/vagrant"
source "$file_path/t2.sql

[vagrant@db-asm-1 ~]$ cat t.2.bak
set file_path "C:\\scripts"
source "$file_path\\t2.sql

[vagrant@db-asm-1 ~]$ ll
total 16
-rw-rw-r-- 1 vagrant vagrant 57 Jan  5 03:26 t.1
-rw-rw-r-- 1 vagrant vagrant 56 Jan  5 03:22 t.1.bak
-rw-rw-r-- 1 vagrant vagrant 56 Jan  5 03:26 t.2
-rw-rw-r-- 1 vagrant vagrant 55 Jan  5 03:22 t.2.bak
drwxrwxr-x 3 vagrant vagrant 18 Jan  5 03:21 working
[vagrant@db-asm-1 ~]$

 

December 26, 2017

UNIFORM_LOG_TIMESTAMP_FORMAT CANNOT BE SET ON ASM INSTANCE (Doc ID 2308274.1)

Filed under: 12.2 — mdinh @ 3:18 pm

Alert.log: New timestamp format in Oracle 12.2

Whats new with the timestamp format in Oracle 12c Release 2?

UNIFORM_LOG_TIMESTAMP_FORMAT CANNOT BE SET ON ASM INSTANCE (Doc ID 2308274.1)

It's expected behavior.  UNIFORM_LOG_TIMESTAMP_FORMAT parameter can't be set on ASM instance in 12.2.0.1.

It will be implemented in future release 18.1.

December 17, 2017

Not Another adrci Examples

Filed under: 12c,adrci — mdinh @ 4:30 am

I know there are a lot of blog posts on ADRI, etc…

However, none of them solved what I was looking for, “How to show all specific problems?”


--- When there are more than 50 incidents
50 rows fetched (*** more available ***)
show incident -all

--- Show specific problem for ORA errors
show problem -all -p "problem_key='ORA 1578'"

---Generates the package for the problem id 100 in /tmp
ips pack problem 100 in /tmp

---Generates the package for the incident id 6439 in /tmp
ips pack incident 6439 in /tmp

---Generates the package for the problem with the problem_key 'ORA 1578'
ips pack problemkey "ORA 1578"

---Generates the package with the incidents occurred in last 8 seconds.
ips pack seconds 8

---Generates the package with the incidents occurred
---between the times '2007-05-01 10:00:00.00' and '2007-05-01 23:00:00.00'
ips pack time '2007-05-01 10:00:00.00' to '2007-05-01 23:00:00.00'

December 14, 2017

Using sed to backup file and remove lines

Filed under: awk_sed_grep — mdinh @ 1:13 am
[oracle@racnode-dc1-2 ~]$ cd /u01/app/oracle/12.1.0.2/db1/rdbms/log/

--- DDL will fail since datafile is hard coded!
[oracle@racnode-dc1-2 log]$ cat tablespaces_ddl.sql
-- CONNECT SYS
ALTER SESSION SET EVENTS '10150 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10904 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '25475 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10407 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ';
-- new object type path: DATABASE_EXPORT/TABLESPACE
CREATE UNDO TABLESPACE "UNDOTBS1" DATAFILE
  SIZE 26214400
  AUTOEXTEND ON NEXT 5242880 MAXSIZE 32767M
  BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

   ALTER DATABASE DATAFILE
  '+DATA/HAWK/DATAFILE/undotbs1.260.962253853' RESIZE 152043520;
CREATE TEMPORARY TABLESPACE "TEMP" TEMPFILE
  SIZE 213909504
  AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M
  EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576;
CREATE UNDO TABLESPACE "UNDOTBS2" DATAFILE
  SIZE 26214400
  AUTOEXTEND ON NEXT 26214400 MAXSIZE 32767M
  BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

   ALTER DATABASE DATAFILE
  '+DATA/HAWK/DATAFILE/undotbs2.265.962254263' RESIZE 235929600;
CREATE TABLESPACE "USERS" DATAFILE
  SIZE 5242880
  AUTOEXTEND ON NEXT 1310720 MAXSIZE 32767M,
  SIZE 4194304
  LOGGING ONLINE PERMANENT BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
 NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;

   ALTER DATABASE DATAFILE
  '+DATA/HAWK/DATAFILE/users.269.962674885' RESIZE 5242880;

--- Remove ALTER and RESIZE from sql file.
--- Most likely the incorrect way to do this since TBS may be undersized.

12.2 Datapump Improvements actually does this the right way.

[oracle@racnode-dc1-2 log]$ sed -i.bak '/ALTER DATABASE DATAFILE\|RESIZE/ d' tablespaces_ddl.sql

[oracle@racnode-dc1-2 log]$ ls -l tablespace*
-rw-r--r-- 1 oracle dba 1214 Dec 14 02:03 tablespaces_ddl.sql
-rw-r--r-- 1 oracle dba 1488 Dec 14 01:45 tablespaces_ddl.sql.bak

[oracle@racnode-dc1-2 log]$ diff tablespaces_ddl.sql tablespaces_ddl.sql.bak
14a15,16
>    ALTER DATABASE DATAFILE
>   '+DATA/HAWK/DATAFILE/undotbs1.260.962253853' RESIZE 152043520;
24a27,28
>    ALTER DATABASE DATAFILE
>   '+DATA/HAWK/DATAFILE/undotbs2.265.962254263' RESIZE 235929600;
32a37,38
>    ALTER DATABASE DATAFILE
>   '+DATA/HAWK/DATAFILE/users.269.962674885' RESIZE 5242880;

[oracle@racnode-dc1-2 log]$ cat tablespaces_ddl.sql
-- CONNECT SYS
ALTER SESSION SET EVENTS '10150 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10904 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '25475 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10407 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT FOREVER, LEVEL 1';
ALTER SESSION SET EVENTS '22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ';
-- new object type path: DATABASE_EXPORT/TABLESPACE
CREATE UNDO TABLESPACE "UNDOTBS1" DATAFILE
  SIZE 26214400
  AUTOEXTEND ON NEXT 5242880 MAXSIZE 32767M
  BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

CREATE TEMPORARY TABLESPACE "TEMP" TEMPFILE
  SIZE 213909504
  AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M
  EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1048576;
CREATE UNDO TABLESPACE "UNDOTBS2" DATAFILE
  SIZE 26214400
  AUTOEXTEND ON NEXT 26214400 MAXSIZE 32767M
  BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

CREATE TABLESPACE "USERS" DATAFILE
  SIZE 5242880
  AUTOEXTEND ON NEXT 1310720 MAXSIZE 32767M,
  SIZE 4194304
  LOGGING ONLINE PERMANENT BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
 NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;

[oracle@racnode-dc1-2 log]$
Next Page »

Create a free website or blog at WordPress.com.