Posts

Showing posts from November, 2018

Redologs - Command Line Examples

Test Redo group 1 redo01a.log /u02a/redologs/fox/   - remove redo01b.log /u02a/redologs/fox/   - remove redo01c.log /u02a/redologs/fox/   - remove redo1a.log /u02a/redologs/fox/    - add redo1b.log /u02b/redologs/fox/    - add Test Redo group 2 redo02a.log /u02b/redologs/fox/   - remove redo02b.log /u02b/redologsfox/   - remove redo02c.log /u02b/redologs/fox/   - remove redo2a.log /u02a/redologs/fox/    - add redo2b.log /u02b/redologs/fox/    - add ALTER DATABASE   ADD LOGFILE GROUP 3 ('/u02a/redologs/fox/redo3a.log', '/u02b/redologs/fox/redo3b.log')       SIZE 51200K; select * from v$log; check inactive ALTER DATABASE ADD LOGFILE MEMBER '/u02a/redologs/fox/redo1a.log' TO GROUP 1; ALTER DATABASE ADD LOGFILE MEMBER '/u02b/redologs/fox/redo1b.log' TO GROUP 1; ALTER DATABASE DROP LOGFILE MEMBER '/u02a/redologs/fox/redo01a.log'; ALTER DATABASE DROP LOGFILE MEMBER '/u02a/redologs/fox/redo01b.log'; ALTER DATABASE DROP LOGFI

MYISAM Locking Explained

Why Table Locking Occurs in MyISAM Locks exist, in a nutshell, to prevent queries from altering data while that data is being read by another process. Or vice-versa. There are different types of locking in the database world. MyISAM happens to use table locks which are very fast. They are easier to implement when compared to the row-level locking employed by InnoDB and permit a higher query throughput. That assumes of course the number of writes that occur on your database is few. Or, and this is sometimes overlooked, that no one query takes more than an instant. After all it's the being locked out that hurts — writes tend to go through pretty quickly — but if they have to wait for a query to complete... Imagine The Scenario 0.00 seconds A select query (ie. read-only) accesses the table, it will take around 2 seconds to complete. 0.01 seconds Another select query accesses the table, it takes no time and will complete in an instant as it can run in paral

Guaranteed Restore Points Oracle

Guaranteed Restore Points are a life-saver when it comes to Application changes.It can ensure that you can rewind the database to a time without tradional point in time recovery. Guaranteed restore points are basically alias’es for SCN’s A normal restore point assigns a restore point name to an SCN or specific point in time.The control file can maintain a record of thousands of normal restore points with no significant effect on database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance. SQL> CREATE RESTORE POINT before_upgrade; Creating a normal restore point eliminates manually recording an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query. Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the con

Oracle Query Tuning and Optimization Techniques

With the overwhelming hits from allover the world for my blogs I thought of sharing some performance tuning methods with all.Performance is a parameter, which is critical for any application. Since no users will be willing to compromise on performance of his system, we are subjected to develop a system with less response time and greater throughput.Oracle is one of the widely use database in the world. We will go through some optimization technique that can be implemented to develop  better systems. Avoid data type mismatch for index columns Most people, who are novice in database use single quote (in the filter condition) irrespective of the data-type they are querying.This makes oracle to do an internal typecast to the required data-type. Before Optimization After Optimization select name,age,city,state from employee where employee_id='111'; select name,age,city,state from employee where employee_id= 111 ; Time taken : 2.3 sec Time tak

Oracle - Applying PSU/CPU on Grid Home

Image
This process was tested and documented on test server which is running a test database on +ASM version 12.1.0.2 and I was applying PSU 181016 (October 2018) Check the Status of the Databases and Listener(s) Check the status of the Cluster Ready Services - using the crstat.py (V12 compatible) Or you can use the crsctl stat res -t - which is the Oracle standard command Download the appropriate patch for the Grid Infrastucture and place them in the /home/oracle/installers directory. Unzip the GI patch and then check you have the correct version of Opatch to perform the installation. Use the opatch analyze command as user root to check if the patch can be applied [root@cdcol7test OPatch]# opatchauto apply /home/oracle/installers/PSU/28349311 -analyze OPatchauto session is initiated at Thu Oct 18 10:00:08 2018 System initialization log file is /app/oracle/product/12.1.0/grid/cfgtoollogs/opatchautodb/systemconfig2018-10-18_10-00-14