Database Solutions

The Calibrate I/O feature is based on a PL/SQL function called DBMS_RESOURCE_MANAGER.CALIBRATE_IO(). When Calibrate I/O is invoked it will generate I/O intensive read-only random I/O (db_block_size) and large-block (1MByte) sequential I/O workloads. Unlike various external I/O calibration tools, this tool uses the Oracle code stack and runs in the database, issuing I/O against blocks stored in the database. The results, therefore, much more closely match the actual database performance. Once the workload execution is completed, a summary of the results is provided. The results from Calibrate I/O should be gauged against the expected throughput rate (the maximum overall throughput of the I/O subsystem). I/O calibration can be used to evaluate the performance of the storage subsystem and determine whether I/O performance problems stem from the database host or the storage subsystem. The Oracle PL/SQL package DBMS_RESOURCE_MANAGER.CALIBRATE_IO is used to execute the calibration. The...

 For DBA a lot of things need to be consideration when migrating database. In this blog, we will discuss one of the concepts "Instance Caging" for migration and consolidation to Exadata Machine.   Oracle offers a simple and effective approach to server consolidation called “Instance Caging”. Instance Caging focuses on managing CPUs by limiting the CPU usage of an Oracle database instance. Where multiple databases are hosted in an Exadata environment, the relative assignment of resources between the two DBRM controllers can be balanced by using Instance Caging. Instance Caging limits the amount of CPU an Oracle database instance consumes by using the Oracle Database Resource Manager and the cpu_count parameter. The cpu_count parameter specifies the CPU usage limit. When multiple performance-critical database instances share a server, as in the case of Cummins Engine, the approach the DBA should take would be to partition the CPUs among the database instances, thus shield...

 The Oracle Database Resource Manager allows The database more control over how hardware resources are allocated. In an environment with multiple concurrent user sessions that run jobs with differing priorities, all sessions should not be treated equally. The Resource Manager enables you to classify sessions into groups based on session attributes, and to then allocate resources to those groups in a way that optimizes hardware utilization for your application environment. With the Resource Manager, you can: Guarantee certain sessions a minimum amount of processing resources regardless of the load on the system and the number of users. Dstribute available processing resources by allocating percentages of CPU time to different users and applications. In a data warehouse, a higher percentage can be given to ROLAP (relational online analytical processing) applications than to batch jobs. Limit the degree of parallelism of any operation performed by members of a group of users. Create a...

 Today We come across an issue where we were unable to stop database using srvctl and session for the srvctl hands.  While checking the status for the instance, we found that STATE for Instance was "Monitor disable" and srvctl saying database is running.  srvctl status database -d dbm Instance dbm1 is running on node node1   Instance  dbm2  is running on node node2 ora.dbm.db      1        ONLINE  ONLINE        node1        MONITOR DISABLED,STABLE      2        ONLINE  ONLINE        node2         MONITOR DISABLED,STABLE Cause:  Seems the agent had issues in the past leaving the resource in MONITOR DISABLED, which is preventing to manage the DB. We do not have the information to understand the reason why the resource went into that state Solution: Kill...

  As DMA its regular activity to patch exadata machine. There are two ways of patching Exadata box Rolling and Non-Rolling. In this blog, we will start with part 3 of the Exadata (Half Rack) Image Upgrade (Non-Rolling). Precheck: Exadata Image Upgrade  Oracle recommends to clear all the stateful alrts from all the cell nodes [root@abcxyzadm01 ~]# dcli -g  cell_group -l root "cellcli -e list alerthistory attributes name,beginTime,alertShortName,alertDescription,severity where alerttype=stateful and severity=critical" Based on Exachk report check if Oracle finds any hardware failure which much be fixed before you proceed for the patching. Compute Node/ DB Note / YUM Patch Plan (Non-Rolling)  Check image version dcli -l root -g dbs_group imageinfo -versio dcli -l root -g dbs_group imageinfo -status dcli -l root -g dbs_group uname -r Verify dbnodeupdate script version  Download latest version of dbnodeupdate script from patch 21634633 Download dbserver.patch.zi...

  As DMA its regular activity to patch exadata machine. There are two ways of patching Exadata box Rolling and Non-Rolling. In this blog, we will start with part 3 of the Exadata (Half Rack) Image Upgrade (Non-Rolling). Precheck: Exadata Image Upgrade  Oracle recommends to clear all the stateful alrts from all the cell nodes [root@abcxyzadm01 ~]# dcli -g  cell_group -l root "cellcli -e list alerthistory attributes name,beginTime,alertShortName,alertDescription,severity where alerttype=stateful and severity=critical" Based on Exachk report check if Oracle finds any hardware failure which much be fixed before you proceed for the patching. Cell Node/ Cell Server Patch Plan (Non-Rolling)  update using the patchmgr utility.Unzip the update. It will extract into the patch_XXXXXX directory. Stop agents if running (Non-Rolling) Check agents and restart if not running  ps -ef | grep agent | grep java | sed 's/\s\+/ /g' | cut -d " " -f 1,8 | sed 's/\/jdk.*//' ...