Question 5, 6

• Which three actions are performed by the Oracle Preinstallation RPM, oracle-database-server-xxxx-preinstall, for Oracle Grid Infrastructure, where xxxx is the Oracle version and release? (Choose three.)

A. performing checks to ensure minimum configuration requirements for Oracle Grid Infrastructure are met

B. creating the oracle OS user

C. creating the OSDBA (dba) group

D. creating the oraInventory (oinstall) group

E. creating the grid OS user

F. configuring the OS for Oracle Automatic Storage Management shared storage access

 

Correct Answer: BCD

Not much are needed to explain for this question. Here is a link with related information.

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/about-the-oracle-preinstallation-rpm.html#GUID-C15A642B-534D-4E4A-BDE8-6DC7772AA9C8

• Which two are true about common objects? (Choose two.)

A. They can be created only in CDB$ROOT.

B. They can be only metadata-linked in an application container.

C. They can exist in user-defined schemas only in application containers.

D. They can exist in CDB$ROOT and an application root.

E. They can be extended data-linked in CDB$ROOT.

F. They can be created only in an application root.

 

Correct Answer: DE

1z0-083

 my 1z0-083 posts:

https://www.linkedin.com/posts/kenchendz_multitenant-usertablespaces-clause-in-activity-7039298088187961344-chDS?utm_source=share&utm_medium=member_desktop

https://www.linkedin.com/posts/kenchendz_multitenant-usertablespaces-clause-in-activity-7039305152511545344-Q-Yq?utm_source=share&utm_medium=member_desktop

More to come...

A mystery issue

A mystery issue just got resolved.

A team complained to me that one of their jobs sometimes failed and sometimes worked well. The job calls a database stored procedure to write a CSV file to a directory on the database server.

So they engaged both the Unix admin and me, the DBA. I had them run the job manually from the server locally using SQLplus, and it worked. Unix admin checked the privileges on the directory and it was 777. 

So I am very sure nothing is wrong on the database server side. Even they insisted that the only thing that changed was that we patched the database server last week.

At first, I thought it was a network blip. But the network team stated there were no issues or maintenance.

Then, I asked the app team to provide the tnsnames.ora file. The TNS entry explains the issue. There were two entries in one that was used to connect to the database. One is pointing to the DR and the other is pointing to Primary. When the primary is used, it works. When the DR is picked, it fails.

The app team said they just copied and pasted so they didn't check.

Sigh...

12c OCM note 02 -- database Vs instance / CDB architect / connect to CDB, PDBs/ Tools

database Vs instance
=================
11g:
single instance: one database -- one instance
RAC: one database -- two or more instances

12c:
non-CDB: same as 11g
CDB:
single instance: one or more databases -- one instance
RAC: one or more databases -- two or more instances




CDB architect
=================
One instance is shared by multiple databases(cdb$root, pdb$seed, other pdbs)


Connect to CDB, PDBs
=================

Connect to root： sqlplus / as sysdba conn / as sysdba

EZ connect： sqlplus sys/oracle@localhost/PRODCDB.example.com:1521 as sysdba sqlplus sys/oracle@host02/PRODCDB.example.com:1521 as sysdba sqlplus sys/oracle@192.168.59.59/PRODCDB.example.com:1521 as sysdba

tns： sqlplus sys/oracle@tns_prodcdb as sysdba

switch container：

alter session set container=cdb$root; Connect to PDB： EZ connect： sqlplus sys/oracle@localhost/pdbprod1.example.com:1521 as sysdba sqlplus sys/oracle@192.168.59.59/pdbprod1.example.com:1521 as sysdba tns： sqlplus sys/oracle@tns_pdb1 as sysdba switch container： alter session set container=PDBPROD2; ---Some useful views col name format a20 col pdb format a10 select name,pdb from cdb_services order by con_id; select name,pdb from v$services order by con_id;

Tools
=================
SQL developer
OEM
TOAD --- Not recommended.

Dataguard -- what if primary has deleted the archive logs standby have not applied yet

STANDBY:
1.Get last SCN  number on Standby database
SQL>  select current_scn from v$database;
2.Stop the managed standby apply process:
SQL> alter database recover managed standby database cancel;
3.Shutdown the standby database
 SQL> shutdown immediate;


PRIMARY:
4.On the primary, take an incremental backup from the SCN number where the standby has been stuck:
RMAN>
run {
  allocate channel c1 type disk;
  allocate channel c2 type disk;
  allocate channel c3 type disk;
  allocate channel c4 type disk;
  backup incremental from scn xxxx database
    FORMAT '/db_backup/RMAN/temp/incr_standby_%U';
  }

5.On the primary, create a new standby controlfile:
SQL> alter database create standby controlfile as '//DEL1_standby.ctl';
Copy these files to standby host:
6.Scp the files to standby server
$ scp * oracle@:

STANDBY:
7.Bring up the instance in nomount mode:
SQL>   startup nomount

8.Check the location of the controlfile and Replace all controlfiles with the one you just created in primary.
SQL>    show parameter control_files
cp //DEL1_standby.ctl 
--for ASM, use RMAN to restore control file
RMAN> restore controlfile from '/db_backup/RMAN/temp/xxxxx_4standby.ctl';

9.Mount the standby database:
SQL>   alter database mount standby database;

10.Make sure the recovery is not started
SQL>    alter database recover managed standby database cancel;

11.RMAN Catalog the files and recover database noredo.
$rman target=/
RMAN>  catalog start with '';
Recover these files:
RMAN> switch database to copy; --if primary and standby use different paths
$RMAN>   recover database noredo;

12.Restart the broker on standby.(if you are using dg broker)
SQL> alter system set dg_broker_start=false scope=both;
SQL> alter system set dg_broker_start=true scope=both;

13.Start recovery on standby.
SQL>   alter database recover managed standby database disconnect from session;

Dataguard -- Gap solutions

To manually resolve gap for physical standby
select * from v$archive_gap;
--to find out the low and high seq# so you know which archive logs are missing
scp these files from primary to standby archive log location
alter database register logfile 'xxxxxxx';

Dataguard -- useful views

V$MANAGED_STANDBY -- lgwr, rfs, lns, arch, mrp information
V$ARCHIVED_LOG -- logs received by standby
V$LOG_HISTORY -- archive history details
V$DATAGUARD_STATUS -- dataguard messages/errors written to alert log and/or trace files
V$RECOVERY_PROGRESS -- recovery information
V$STANDBY_EVENT_HISTOGRAM -- log applying lag histogram
DBA_LOGSTDBY_LOG -- applied log information
DBA_LOGSTDBY_EVENTS -- log applied events in alert log
V$LOGSTDBY_PROCESS -- log apply processes current status