Sunday, December 31, 2023

I Cannot Participate in the Genocide | I Quit Blogging on Oracle Products

Since Oracle declared its "stand with Israel", it puts me in a moral dilemma, in one hand my main intention of blogging was to share the knowledge without any intention of promoting Oracle/or any other database vendor products, but in the other hand and during the period of joining Oracle ACE program, it was crystal clear for me that we were playing a major rule in promoting Oracle products through our blogs and websites.

I admit that my blog will not make any difference in that regard, it's like a drop in the ocean, but at least I'll not "indirectly" promote the products of a company that supports the horrific crimes against P@lastinians.

 For the time being, I'll resume back after this genocide in G@za stops, when I'm back, I'll write articles on open source database products.

In case you are not aware of what is happening in G@za:

Israel losing global support over "indiscriminate bombing" ofGaza bombing, Biden says

Nearly 70% ofGaza’s 439,000 homes and about half of its buildings have been destroyed

The bombing has killed one per cent ofGaza's entire population. Allied bombing of Germany, by comparison, killed a smaller percentage of the German population over the course of the entire Second World War. 

damning-evidence-of-war-crimes-as-israeli-attacks-wipe-out-entire-families-ingaza/


Monday, June 26, 2023

ORA-00479: RVWR process terminated with error

 Problem:

When trying to enable flashback feature on a 19c DB I get this error:

 26-Jun-2023 16:03:25 SYS@fq> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-00479: RVWR process terminated with error


Analysis:

Current SQLPlus session settings can contribute in getting this error.

Solution:

Connect to SQLPlus using "nolog" option, where login.sql will not be effective, then enable the Flashback feature:

[oracle@fq ~]$ sqlplus /nolog

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jun 26 16:10:52 2023
Version 19.5.0.0.0

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

SQL> conn / as sysdba
Connected.

SQL> alter database flashback on;

Database altered.


Friday, June 9, 2023

Automatic Cleanup of Flashback Logs when FRA is Full | New feature in Oracle Database Monitoring Script "dbalarm"

 I've introduced a new feature in dbalarm script to clear all flashback logs whenever the Flash Recovery Area (FRA) hits its defined threshold "FRATHRESHOLD" inside the script. This is the first optional corrective action I include in dbalarm monitoring script. I may add more optional corrective actions in the future if I feel it was easy understood and utilized by DBAs.

I feel that since Oracle 10g, Oracle has a chronic problem with cleaning up FLASHBACK Logs  FLBs whenever FRA becomes full, this is why I'm targeting the cleanup of FLBs in this feature.

How this feature works:

When the defined threshold for FRA "FRATHRESHOLD" is reached, the code will check if parameter "FLASHBACK_RESET" inside the script is set to Y, then it will check if FLASHBACK feature is turned ON, if it's ON, it will execute the following commands which will turn Flashback Database feature to OFF then ON to clean up all FLASHBACK logs in FRA:

ALTER DATABASE FLASHBACK OFF;
ALTER DATABASE FLASHBACK ON;


Then it will check again if the script has managed to successfully turn FLASHBACK feature back ON, if the script fails, it will send a Warning Email to the user to notify that the script has failed to turn ON flashback feature, including the commands log in the Email body.

Note: You must consider that resetting the FLASHBACK Database feature will delete all Flashback Logs, and hence this will undermine the ability of flashing back the database to a point in time older than the reset activity.

If the database is a PHYSICAL STANDBY, and the Recovery is running, then extra commands will be executed to maintain a proper reset of Flashback feature on a PHYSICAL STANDBY database:

ALTER DATABASE FLASHBACK OFF;
RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE FLASHBACK ON;
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE NODELAY DISCONNECT;

How to Use this Feature:

First, if you are not familiar with dbalarm script, I strongly recommend you to go through this article first to have an idea of how it works:

http://dba-tips.blogspot.com/2014/02/database-monitoring-script-for-ora-and.html

Download the script:

https://www.dropbox.com/s/a8p5q454dw01u53/dbalarm.sh?dl=0

Second, Set parameter FLASHBACK_RESET=Y at line# 132

Note: This feature is disabled by default, you have to enable it manually to avail it.

Facts you must know:

When FRA is full, Oracle will start creating archivelogs under $ORACLE_HOME/dbs which in most cases doesn't have sufficient space to accommodate Archivelogs!

This script works only on Linux environments, it's well tested on Oracle & Red Hat Linux 6 & 7 but not tested on other flavors and hence you have to test it well in a test environment before using it on production.

DISCLAIMER: THIS SCRIPT IS DISTRIBUTED IN THE HOPE THAT IT WILL BE USEFUL BUT WITHOUT ANY WARRANTY. IT IS PROVIDED "AS IS".

GitHub version:



Tuesday, May 30, 2023

DB_DEVELOPER_ROLE for Developers on 23c

 Oracle 23c comes with a new role called "DB_DEVELOPER_ROLE" packed with sufficient privileges for most developers on non-production systems, rather than assigning them the DBA role which violates the least-privilege security principle.

DB_DEVELOPER_ROLE role is packed with the following privileges:

CREATE TYPE
CREATE MATERIALIZED VIEW
CREATE TRIGGER
CREATE PROCEDURE
CREATE JOB
CREATE SEQUENCE
CREATE VIEW
CREATE SYNONYM
CREATE TABLE
CREATE SESSION
CREATE DOMAIN
CREATE MLE
CREATE ANALYTIC VIEW
CREATE HIERARCHY
CREATE ATTRIBUTE DIMENSION
EXECUTE DYNAMIC MLE
CREATE CUBE BUILD PROCESS
CREATE CUBE
CREATE CUBE DIMENSION
CREATE MINING MODEL
DEBUG CONNECT SESSION
ON COMMIT REFRESH
CREATE DIMENSION
FORCE TRANSACTION
EXECUTE ON SYS.JAVASCRIPT
SELECT ON SYS.DBA_PENDING_TRANSACTIONS
READ ON SYS.V_$STATNAME
READ ON SYS.V_$PARAMETER

Reference:

https://docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/managing-security-for-application-developers.html#GUID-DCEEC563-4F6C-4B0A-9EB2-9F88CDF351D7

TOP command is not showing the processes in a right order

Problem:

I came across a weird problem where top Linux command is not sorting the processes by the top consumer processes under oracle user, but when running top Linux command with any other user it sorts the processes in a right order.
If you still unable to understand the issue, look at this screenshot which shows top command output under oracle user on the left side where the processes are listed randomly, and the same command output ran by opc user on the right side where the processes are sorted by the top consumers.

There is no alias being invoked for top command:

 

Analysis:

There is a file with name ".toprc" under /home/oracle saves top command settings, where it influences top command output. This file get created when you press "W" after calling top command to save its current call setting:

Solution:

I've simply renamed the .toprc file and the top command output is back to its normal setting sorting the processes by top CPU consumers.

# cd ~
# mv .toprc  .toprc.old

 

Conclusion:

This is not a problem, but it's just a wrong configuration impacted the output of top command and also impacted the behavior of all monitoring script that depend on top command output for reporting the top consuming processes.

References:

https://www.thegeekstuff.com/2010/01/15-practical-unix-linux-top-command-examples/