Oracle DBA - DATABASE

What is Block Change Tracking? Block Change Tracking is an Oracle Database feature used with RMAN incremental backups. It tracks the physical locations of changed blocks in the database and stores this information in a separate file called the Block Change Tracking file. Oracle documentation states that this tracking information is maintained in a separate file and is used for tasks such as improving incremental backup performance. Without BCT, RMAN may need to scan the datafiles to determine which blocks have changed since the previous backup. With BCT enabled, RMAN can directly read the change tracking file and identify changed blocks more efficiently. ----- Login to SQL sqlplus / as sysdba            Set lin 400 SELECT status, filename, bytes FROM   v$block_change_tracking; CHECK OMF SHOW PARAMETER db_create_file_dest;  ENABLE BCT (BLOCK CHAIN TRACKING) Common method: ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;  Add to a file path:...

Warning: long redo log write elapsed times detected, the LG* process tracefiles have more details This warning means LGWR / LGnn background processes are taking too long to write redo to the online redo logs. It is usually related to one of these: - Slow storage / high I/O latency on redo log disks - Redo logs placed on busy disks together with datafiles, FRA, archive logs, backups, or OS files - Too many commits from the application, causing frequent LGWR flushes - Redo log size too small, causing frequent log switches - CPU scheduling issue, where LGWR is not getting CPU quickly - Data Guard synchronous transport delay, if using SYNC/AFFIRM - In newer 19c RU versions, especially around 19.28, this warning can appear more visibly because of diagnostic changes, so first confirm whether there is a real performance impact before changing anything. - Oracle’s own wait-event documentation says log file sync is the foreground wait for redo write confirmation after commit, and log file paral...

 C:\iperf3.5_64>iperf3 -c 172.168.1.100 warning: Ignoring nonsense TCP MSS -13312 Connecting to host 172.168.1.100, port 5201 [  5] local 192.168.8.101 port 52570 connected to 172.168.1.100 port 5201 [ ID] Interval           Transfer     Bitrate [  5]   0.00-1.00   sec  6.88 MBytes  57.5 Mbits/sec [  5]   1.00-2.00   sec  3.50 MBytes  29.4 Mbits/sec [  5]   2.00-3.00   sec  4.00 MBytes  33.5 Mbits/sec [  5]   3.00-4.01   sec  6.25 MBytes  52.0 Mbits/sec [  5]   4.01-5.00   sec  4.75 MBytes  40.2 Mbits/sec [  5]   5.00-6.01   sec  5.50 MBytes  45.9 Mbits/sec [  5]   6.01-7.01   sec  5.88 MBytes  49.1 Mbits/sec [  5]   7.01-8.00   sec  5.25 MBytes  44....

VPD Policy Implementation - ORACLE Database  VPD policies Oracle CREATE TEST USERS in DB -- Owner schema for objects CREATE USER app_owner IDENTIFIED BY AppOwner#123 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON users; GRANT CREATE SESSION, CREATE TABLE, CREATE PROCEDURE, CREATE ANY CONTEXT TO app_owner; -- Test application user CREATE USER app_user IDENTIFIED BY AppUser#123 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; GRANT CREATE SESSION TO app_user; CONNECT TO USER CONN app_owner/AppOwner#123  CREATE THE SAMPLE TABLE AND DATA CREATE TABLE employees (     emp_id         NUMBER PRIMARY KEY,     emp_name       VARCHAR2(100),     department_id  NUMBER,     salary         NUMBER ); INSERT TEST DATA   INSERT INTO employees VALUES (1, 'John',  10, 1000); INSERT INTO employees VALUES (2, 'Mary',  20, 1200); INSERT INTO empl...

Check current directory pathes which are on the source database. SELECT directory_name, directory_path FROM dba_directories; create and grant permision to run expdp for the same location which you want to run the backup. CREATE OR REPLACE DIRECTORY DUMP_NEW_DIR AS '/BACKUP'; GRANT READ, WRITE ON DIRECTORY DUMP_NEW_DIR TO SYSTEM; before running the below command create a file in the directory and give permissions as follows, chmod -R 777 export.par vi export.par  DIRECTORY=DUMP_NEW_DIR DUMPFILE=full_db_export_%U.dmp LOGFILE=export.log FULL=Y PARALLEL=2 run the command nohup to run this expdp without enteruptions. nohup expdp system/oracle123 parfile=export.par & check if any exp process are running on the database using below sql command. col owner_name format a12 col job_name format a25 col state format a15 col operation format a10 col job_mode format a12 select owner_name,        job_name,        operation,        job...

  The flash recovery area(FRA) is an Oracle-managed destination( either FILE SYSTEM or ASM ) for centralized backup and recovery files. It simplifies the backup management. The following recovery-related files are stored in the flash recovery area: — Current control file — Online redo logs — Archived redo logs — Flashback logs — Control file auto backups — Datafile and control file copies — Backup pieces — Foreign archived redo log Below are the steps for enabling  flash  recovery area. DB_RECOVERY_FILE_DEST_SIZE   and  DB_RECOVERY_FILE_DEST   initial parameters are required for enabling FRA. DB_RECOVERY_FILE_DEST_SIZE   -> It is the disk quota size for the flash recovery area. DB_RECOVERY_FILE_DEST   – > This initialization parameter is a valid destination for the Flash Recovery Area. It can be a directory, file system, or ASM disk group. NOTE  : DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST. 1. Check whether FRA ...