When things in your life seem, Almost too much to handle,
When 24 Hours in a day is not enough,
Remember the mayonnaise jar and 2 cups of coffee.
A professor stood before his philosophy class
And had some items in front of him.
When the class began, wordlessly,
He picked up a very large and empty mayonnaise jar
And proceeded to fill it with golf balls.
He then asked the students, If the jar was full.
They agreed that it was.
The professor then picked up a box of pebbles and poured
them into the jar. He shook the jar lightly.
The pebbles rolled into the open Areas between the golf balls.
He then asked The students again
If the jar was full. They agreed it was.
The professor next picked up a box of sand
And poured it into the jar. Of course, the sand filled up everything else.
He asked once more if the jar was full. The students responded
With unanimous 'yes.'
The professor then produced Two cups of coffee from under the table
And poured the entire contents Into the jar, effectively
Filling the Empty space between the sand.
The students laughed.
'Now,' said the professor, As the laughter subsided,
'I want you to recognize that “This jar represents your life”.
The golf balls are the important things - God, family,
children, health, Friends, and Favorite passions –
Things that if everything else was lost
And only they remained, Your life would still be full.
The pebbles are the other things that matter Like your job, house, and car.
The sand is everything else --
The small stuff.
'If you put the sand into the jar first,' He continued,
'there is no room for The pebbles or the golf balls.
The same goes for life.
If you spend all your time And energy on the small stuff,
You will never have room for The things that are
Important to you.
So...
Pay attention to the things That are critical to your happiness.
Play With your children.
Take time to get medical checkups.
Take your partner out to dinner.
There will always be time
To clean the house and fix the disposal.
'Take care of the golf balls first --
The things that really matter.
Set your priorities. The rest is just sand.'
One of the students raised her hand
And inquired what the coffee represented.
The professor smiled.
'I'm glad you asked'.
It just goes to show you that no matter how full your life may seem,
there's always room for A couple of cups of coffee with a friend.'
Saturday, September 25, 2010
Some Basic VI Concepts
:%s/DBA//g -To replace the word "DBA" with blank space
:%s/^/DBA/g -To add a Text "DBA" in front of all words
:%s/$/DBA/ -To add a Text "DBA" at the last of all words
:%s/\s\+$// -To remove blank spaces.
:%s/^/DBA/g -To add a Text "DBA" in front of all words
:%s/$/DBA/ -To add a Text "DBA" at the last of all words
:%s/\s\+$// -To remove blank spaces.
Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g
Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g -> Meta link Doc ID:28814.1
ORA-27301: OS failure message: Not enough space
Last week I experienced below error on solaris server.
*** SERVICE NAME:(SYS$BACKGROUND) 2009-02-05 20:14:41.719
*** SESSION ID:(169.1) 2009-02-05 20:14:41.719
*** 2009-02-05 20:14:41.719
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
*** 2009-02-05 20:15:07.770
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5
*** 2009-02-05 21:39:15.391
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
On checking system logs (/var/adm), dmesg and others , Noticed system was nearly out of swap.
As part of immediate resolution bounce database to kill all defunct processes and started the database again.
Metalink note 579365.1 described exactly the same issue
*** SERVICE NAME:(SYS$BACKGROUND) 2009-02-05 20:14:41.719
*** SESSION ID:(169.1) 2009-02-05 20:14:41.719
*** 2009-02-05 20:14:41.719
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
*** 2009-02-05 20:15:07.770
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5
*** 2009-02-05 21:39:15.391
Process startup failed, error stack:
ORA-27300: OS system dependent operation:fork failed with status: 12
ORA-27301: OS failure message: Not enough space
ORA-27302: failure occurred at: skgpspawn3
On checking system logs (/var/adm), dmesg and others , Noticed system was nearly out of swap.
As part of immediate resolution bounce database to kill all defunct processes and started the database again.
Metalink note 579365.1 described exactly the same issue
ORA-00230: operation disallowed: snapshot control file enqueue unavailable
If one RMAN job is already backing up the control file while another needs to create a new snapshot control file, then we may see the following message:
ORA-00230: operation disallowed: snapshot control file enqueue unavailable
Below query will determine which job is causing the wait:
SELECT s.sid, username AS "User", program, module, action, logon_time "Logon", l.*
FROM v$session s, v$enqueue_lock l
WHERE l.sid = s.sid and l.type = 'CF' AND l.id1 = 0 and l.id2 = 2;
ORA-00230: operation disallowed: snapshot control file enqueue unavailable
Below query will determine which job is causing the wait:
SELECT s.sid, username AS "User", program, module, action, logon_time "Logon", l.*
FROM v$session s, v$enqueue_lock l
WHERE l.sid = s.sid and l.type = 'CF' AND l.id1 = 0 and l.id2 = 2;
ORA-1693: max # extents 4096 reached in lobsegment
I faced the below error on one of the production system. while goggling i found a good metalink note: 1014040.102
ORA-1693: max # extents 4096 reached in lobsegment ETS.SYS_LOB0000145096C00007$$
ORA-1693: max # extents 4096 reached in lobsegment ETS.SYS_LOB0000145096C00007$$
Mysql Technical Document -Source Mr.Anandha
Anandkumar formally known as Anandha do assortment research on mysql database and he use to read lot of write ups over internet. The below technical document he got from internet
---------- Forwarded message ----------
From: Anand Kumar
Date: Wed, Sep 8, 2010 at 10:10 PM
Subject: Fwd: master-slave replication sync problems.
Hi Guys,
I found it to be a good writeup about the internal funtion of the replication, worth reading....Hope this will clear all your doubts about the mysql replicaiton.
There are two formats for replication (ROW and STATEMENT) but the general process remains the same. Here is a nutshell summary of the process.
** on the master **
m1) The MySQL master is instructed to change some data.
m2) The data is changed and the results are committed to disk. If you rollback the changes before you commit them, then there is nothing to replicate. Only the InnoDB engine supports this type of rollback.
m3) The change committed in step 2 is written to the binary log
(repeat from step m1 until the Master is shutdown)
** on the slave - the IO thread **
(assuming that the slave is already configured with compatible data, a starting position, and the proper credentials to act as a slave)
o1) The SLAVE IO thread requests information from the master's binary logs. This information is identified by a file name and a byte offset from the start of that file
o2) The SLAVE IO thread copies all available information from the master's binary logs into a local copy of those logs known as the relay logs.
(repeat from o1 until the SLAVE IO thread is stopped(by error or by command) or the slave is shutdown)
** on the slave - the SQL thread **
s1) Once an unapplied change has been completely buffered into the relay logs, the SLAVE SQL thread attempts to apply the change to the slave's data.
s2) If LOG SLAVE UPDATES is enabled, copy the applied change (using the correct format) into the slave's binary log.
(repeat from s1 until the SLAVE SQL thread is stopped (by error or by command) or the slave is shutdown)
**
As you can tell by this very simplified process description, there is no attempt to rectify one dataset to the other. Replication operates under the principle that if you perform identical changes to identical sets of data, you will end up with identical end results.
Various replication "filters" can omit certain changes from either being replicated to or processed by the slave instance. Use these WITH EXTREME CAUTION as they can very easily create situations where the master and slave datasets diverge to the point that a rebuild of the slave data is the only effective repair.
**
When you get a replication error, such as DUPLICATE KEY, it is the administrator's responsibility to figure out why and fix it. Maybe some user on the slave added an extra row to a table? Maybe an INSERT ... SELECT added more rows on the slave than it did on the master? Maybe a DELETE on the master removed less rows than it did on the slave?
Simply skipping those problems (and others) without investigation or correction may allow the two datasets (master and slave) to diverge even more. The human administrator is required to make a judgment call on which version of the conflicting row is the "correct" version. Is is the one on the table or the change coming in from the binary log? Maybe the data on the slave is "correct" but it has been offset by a few rows inserted a long time ago.
It's your responsibility to understand and appropriately respond to the errors not just repeat scripted actions until the problems disappear temporarily.
--
Shawn Green
MySQL Principal Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN
---------- Forwarded message ----------
From: Anand Kumar
Date: Wed, Sep 8, 2010 at 10:10 PM
Subject: Fwd: master-slave replication sync problems.
Hi Guys,
I found it to be a good writeup about the internal funtion of the replication, worth reading....Hope this will clear all your doubts about the mysql replicaiton.
There are two formats for replication (ROW and STATEMENT) but the general process remains the same. Here is a nutshell summary of the process.
** on the master **
m1) The MySQL master is instructed to change some data.
m2) The data is changed and the results are committed to disk. If you rollback the changes before you commit them, then there is nothing to replicate. Only the InnoDB engine supports this type of rollback.
m3) The change committed in step 2 is written to the binary log
(repeat from step m1 until the Master is shutdown)
** on the slave - the IO thread **
(assuming that the slave is already configured with compatible data, a starting position, and the proper credentials to act as a slave)
o1) The SLAVE IO thread requests information from the master's binary logs. This information is identified by a file name and a byte offset from the start of that file
o2) The SLAVE IO thread copies all available information from the master's binary logs into a local copy of those logs known as the relay logs.
(repeat from o1 until the SLAVE IO thread is stopped(by error or by command) or the slave is shutdown)
** on the slave - the SQL thread **
s1) Once an unapplied change has been completely buffered into the relay logs, the SLAVE SQL thread attempts to apply the change to the slave's data.
s2) If LOG SLAVE UPDATES is enabled, copy the applied change (using the correct format) into the slave's binary log.
(repeat from s1 until the SLAVE SQL thread is stopped (by error or by command) or the slave is shutdown)
**
As you can tell by this very simplified process description, there is no attempt to rectify one dataset to the other. Replication operates under the principle that if you perform identical changes to identical sets of data, you will end up with identical end results.
Various replication "filters" can omit certain changes from either being replicated to or processed by the slave instance. Use these WITH EXTREME CAUTION as they can very easily create situations where the master and slave datasets diverge to the point that a rebuild of the slave data is the only effective repair.
**
When you get a replication error, such as DUPLICATE KEY, it is the administrator's responsibility to figure out why and fix it. Maybe some user on the slave added an extra row to a table? Maybe an INSERT ... SELECT added more rows on the slave than it did on the master? Maybe a DELETE on the master removed less rows than it did on the slave?
Simply skipping those problems (and others) without investigation or correction may allow the two datasets (master and slave) to diverge even more. The human administrator is required to make a judgment call on which version of the conflicting row is the "correct" version. Is is the one on the table or the change coming in from the binary log? Maybe the data on the slave is "correct" but it has been offset by a few rows inserted a long time ago.
It's your responsibility to understand and appropriately respond to the errors not just repeat scripted actions until the problems disappear temporarily.
--
Shawn Green
MySQL Principal Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN
Tuesday, September 14, 2010
Some Useful linux commands for DBA's
I found this linux commands to be very useful for the DBA's from the oracle site...
Hope you people definitely find it to be useful tooo...
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part1.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part2.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part3.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part4.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part5.html
Hope you people definitely find it to be useful tooo...
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part1.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part2.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part3.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part4.html
http://www.oracle.com/technology/pub/articles/advanced-linux-commands/part5.html
Ravikumar @Oracle
This Blog is created for a technical group of people who have good experience on their primary domains and to get connected on their technical experience, fun….etc to share on one common storage database..
Subscribe to:
Posts (Atom)