腓立比書 4:6-7

 《經文：腓立比書 4:6-7》

6應當一無罣慮，只要凡事藉著禱告、祈求和感謝，將你們所要的告訴神。7神所賜出人意外的平安，必在基督耶穌裡，保守你們的心懷意念。

Question 7, 8, 9, 10

Which two are true about the Automatic Database Diagnostic Monitor (ADDM)? (Choose two.)

A. It analyzes a period of time corresponding to the 12 hours of activity.

B. It runs automatically after each AWR snapshot.

C. A DBA can run it manually.

D. Results are written to the alert log.

E. It analyzes a period of time corresponding to the last day of activity.

Correct Answer: BC

A: ADDM analyzes the data collected between two AWR snapshots, which is typically a one-hour period. So 12 hour period is wrong.

B: ADDM runs automatically after each AWR snapshot, which is typically every hour by default.

C: The DBA can also manually run ADDM by calling the sql scripts under rdbms/admin directory. 

D: ADDM is not written to alert log. The results are saved in the database.

E: Not to the last day of activity.

Which two are true about server-generated alerts? (Choose two.)

A. Stateful alerts must be cleared by a DBA after resolving the problem.

B. Stateless alerts can be purged manually from the alert history.

C. Stateless alerts can be cleared manually.

D. Stateless alerts are automatically cleared.

E. Stateful alerts are purged automatically from the alert history.

Correct Answer: BC

The database considers all the non-threshold alerts as stateless alerts. A stateful alert first appears in the DBA_OUTSTANDING_ALERTS view and goes to the DBA_ALERT_HISTORY view when it is cleared. A stateless alert goes straight to DBA_ALERT_HISTORY.(http://www.remote-dba.net)

For metric alert event types, an event (metric alert) is raised based on the metric threshold values. These metric alert events are called stateful alerts. For those metric alert events that are not tied to the state of a monitored system (for example, snapshot too old, or resumable session suspended ), these alerts are called stateless alerts. Because stateless alerts are not cleared automatically, they need to be cleared manually.

Which three are located by using environment variables? (Choose three.)

A. the Optimal Flexible Architecture (OFA) compliant path to store Oracle software and configuration files.

B. the location of Oracle Net Services configuration files

C. the list of a disk group names to be mounted by an Oracle Automatic Storage Management (ASM) instance at startup

D. default directories for temporary files used by temporary tablespaces

E. the temporary disk space used by Oracle Installer during installation

F. the maximum number of database files that can be opened by a database instance

Correct Answer:  ABE

A: ORACLE_BASE, ORACLE_HOME 

B: TNS_ADMIN

C: Not env variables but in ASM pfile/spfile.

D: Not env variables but by controlfile.

E: TMP, TEMP

F: Not env variables but in database pfile/spfile.

Which three are true about opatchauto? (Choose three.)

A. It performs a shutdown and then a restart of all processes in both Oracle Grid Infrastructure and Oracle Database home during the patching process.

B. It must be invoked by a user with root user privileges.

C. Patches are applied via opatchauto.

D. Users must always input patch plans to opatchauto.

E. It requires the Oracle Grid Infrastructure and Oracle Database instances to be shut down before being invoked.

F. It applies patches in nonrolling mode by default.

G. It is used to apply interim patches to Oracle Grid Infrastructure and Oracle Database home combinations.

Correct Answer: BCE  BCG

A. Totally wrong statement.

B. Yes you have to use root.

C. True.

D. Patch plan is optional.

E. opatchauto performs shutdown and restart so this is false.

F. It can do rolling patch for RAC systems.

G.True. It patches both GRID and RDBMS homes.

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;