After going through Tarry reply u forgot to look under it which explains a good quotation
ONE MUST LEARN TO WALK BEFORE (S)HE CAN FLY
I hope u will end confronting with senior DBA's now.
To accept "ethics" one needn't be a Senior DBA. One has to be "human"...that is all is necessary.
Originally posted by akhadar
I hope u will end confronting with senior DBA's now.
Its a shame that such seniors here are made moderators.
I shall not intervene any further. I have known certain senior members like Sambavan to be very matured. I just hope they will appreciate and accept my view points here.
As for others, I shall ignore them. No hard feelings, I shall resign out of this....its already developed too far (which I didn't intend).
I remember some 10 years back an engineer on board started a discussion about "what is it to be a great brain surgeon???Or a super Psychologist???
He argued how can one human brain judge another???
I read also somewhere about the IQ tests that it is adjusted by the examining authorities in order to compensate the male and the female rationalization techniques(again based on study,cases etc ,again judged by one or more humans).So that both genders can score reasonably.
I started writing a book in 97(it's still in the pipeline..no story telling like jk rowling or contused like rushdie but about hindu mythology,human brain,etc). It'll probably help us to look at every definition that is a definition from the 6th dimension.
Bottom Lineon't judge people , knowledge is up for grabs, now more than ever. Ofcourse pando's advise is good but so is dbafreak's opinion of interactive learning. Oracle is one of the many manifestations of a human brain, the power of reasoning.
Lets just give each other space and keep picking the good things out of all the inputs.
Tarry Say: One who seeks will find!
I'm a JOLE(JavaOracleLinuxEnthusiast)
--- Everything was meant to be
Very well said Tarry. Now, lets come back and get life to this wonderful thread. Could you please spare some time for my question. I am struck with this here. Kindly explain.
Listen, you just sleeped to some principial considerations, here, and this isn't right ok, because the purpose of a forum is people to communicate. If somebody have something to ask, asks, and if somebody feels like wants to answer, answers. Of course, the questionner takes the risk to ask too frequently simple or boring thinks, but who we are to judge??? Maybe he/she reads tones of documentation, and still doesn't understand!
It is simplier to say that:
IF a commited transaction isn't reflected in data written on disk, because of the non-syncronous wrtiting policy of DBWRn, it HAVE to commit at recovery time. If an uncommited transaction IS reflected in data on the disk, it HAVE to rollback those data changes. This is where the rollback phase happens.
The commited transactions never rollback.
Maybe would be more usefull if we introduce the expression "finished transaction" - this meaning either rollbacked or commmited.
A failure may occure at any time, in very different situations. All you have to know is that the DBWR, LOGWR and server processes are mostly INDEPENDENT one of another. Only checkpoints are introducing some consistency here, but this consistency last VERY short time on a highly loaded database.
Oracle needed a very safe mecanism to manage the sincronization and the consistency, or let's say, transaction processing, a very safe and simple mecanism, but a performant one. The DBWR HAVE to be asincronous, because this is what a database engine does!
In think know very well which is the missunderstanding of dbafreak. And, in my oppinion, the correct hint for him/her is: think about recovery ONLY FROM THE LAST CHECKPOINT! And you'll undestand, I think.
If you still don't understand, put the question in more specific way, because I can't give you a very ellaborated answer to a non-ellaborated question.
I hope I was for help. Bye!
Thanks for the time and patience ovidius. I shall make my question very clear. Kindly answer me:
1)Lets assume I have updated 100 rows of data, but did not commit. Assume a power failure happens or say the DB crashes etc.
2)Now we have redologs. So we first Roll Forward to bring the database forward. At this juncture the database contains both committed and uncommitted data.
3)The next step we do a rollback, so that the database cleans the uncommitted transactions and retains only the committed.
I understand this is the way Oracle is designed.
Observe points (2) and (3). At the juncture of point (2), we have both committed and uncommitted data in the database. Its exactly the same state as when the DB crashed / Power failed. That is -- the 100 rows I updated are still available at this juncture (Assuming they were written to the datafiles).
Now by executing point (3) - which is what Oracle does - I lose all these updates as its rolled back. Which means I have to redo all my 100 updates again.
SO -- Why doesn't Oracle stop with step (2) itself? That way I can retain my uncommitted data. Why does Oracle have to rollback thereby forcing me to redo all my updates again.
Hope my question is clear. Kindly answer anyone who knows the answer.
Thanks in advance.
now assume that you've executed a script for updating two tables which are virtually linked together. now when the power failure occurs, 100 rows of first table are modified but only 50 rows of second tables are modified and 50 are still pending. so do u think that ORACLE should not rollback this transaction. cause the last state i.e. before updation started is a consistent state and where the oracle is running without any inconsistency and now after the partial updation the database is not in a consistent state.
to give more expn, oracle is said to be in consistent state when the SCN is same in control files, redo records and data file headers. i'm i right??
if i'm still missing something let me know
8i OCP DBA
It is very simple: the session which made the changes must either commit or rollback. Even the same oracle user can't commit changes made by this same oracle user in another session. Even the most superpower user SYS can't commit other's sessions transactions.
If the session that made the changes unexpectedly dies, those changes must automaticaly be rolled back by PMON, because Oracle knows that session will never be established again, so the original author of the changes will not be able to commit or rollback. So the only safe method is to make the system look like those changes were never actually entered.
Now after instance recovery if Oracle would stop after rollforward, there would be some changes pending there forever, as the sessions that made them are dead and will never be alive again. So what other choice does oracle have but to rollbackj all those changes? It can't simply commit them for many reasons. For example, because of the possible referencial inconsistencies caused by unfinished transactions. Or because maybe you as the author of those changes might decide that you actually want to rollback those changes if the instance had not crashed...
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
Jmodic and Santosh: Thanks a lot for the answers. This is what I was looking at exactly. Thanks again. This answers my question very nicely.
very well explained Jurij. now thats what i call a very technical answer.
8i OCP DBA
Click Here to Expand Forum to Full Width