- I'd Like to Help, But...
- What Concerns Me Is...
- Oracle Will Make You Thinner and Better Looking?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Oracle Will Make You Thinner and Better Looking?
In the Oracle store down the street, on the better side of town I might add, you can be looking all day long at what is available, even if I'm past looking, and I am actually in the process of picking something. Maybe the juice section is much wider. Maybe I'm even thinner in the Oracle store. Who knows? Either way, I haven't actually made a selection yet, so why should you be prevented from seeing what's available? Maybe I will take the last cranberry-grape juice. Maybe I won't. But where's the harm in you seeing what's there so you can call your wife to tell her "I forgot what you wanted, but here's what's available..."
You see, with Oracle, as far as readers are concerned, there is no long, drawn-out process of updating a row. No, I might be modifying a row in memory, but as far as others are concerned, that row has not been updated until I've actually issued a commit. After all, I might be a bad programmer and be holding that row for a long time before committing it. Or I might decide that I don't want to change the row at all and I just roll it back. So a change has never taken place at all, but either way, you can go on about your business, unaware that I'm even logged on, much less in the process of updating. Once I modify a row and issue a commit, however, the row is changed, and only then do you read the new value. Because only then does the new value officially exist.
You might be thinking that it's a small difference. But I can tell you it is a crucial one. When you have to support a system with several concurrent updates occurring to the same ranges of the same table, all the while users are querying the data you're working on, you'll find out how quickly the "reader-blocks-writer" mechanism will stop production. And that, in an enterprise system, is simply not acceptable.
Maybe we'll get into other architectural issues at some future point in time. Issues such as the following:
- Lock escalation due to lack of memory
- SQL Server returning bad data due to its inability to support read consistency
- Time-consuming maintenance tasks such as DBCC to detect/prevent corruption
- Microsoft's "self-tuning" database, which in many cases hinders the DBA
- SQL Server's lack of scalability, despite humorous TPC results
Of course, there are many more to address, but I have other things to do now. I'll schedule a class real soon.