MERGE Without an INSERT — It’s Not Always Like an UPDATE

Before you proceed with reading this post, I strongly encourage you to read Tom Kyte’s trilogy about write consistency, since I’ll do only a brief introduction to the subject. The way Oracle ensures UPDATE write consistency is through a mechanism called restart. Let’s take a look at an example before we proceed with the main topic of this blog post, Will there be any difference if we substitute the following MERGE for the last UPDATE?

OTN Forums Developers Heard My Voice

A few month ago I posted about my indignation regarding the inability to change my email address on OTN. Now, I’m not only able to change my email address, but also the screen name (I don’t think I do that before either). In the end, it took Oracle just 2 months and 5 days to follow up on my post. Not too bad, considering that OTN forums were full of complaints for years! ;-)

Can “between” and “>= and <=” Differ in Oracle?

Let’s take the following question, for example. Is there any difference between using: where column between n and m and where column>=n and column<=m? Looks like a simple one, eh? hey are the same from a semantic point of view. But SQL is a declarative language. In other words, you wouldn’t expect same execution plan with two semantically identical statements, would you? There is at least one known (to me) example where both statement produce different execution plans. You never know until you test it. We start by creating a simple list-partitioned table with the local index:

mysql> set global innodb fast=true;

So you ran into some basic limitations with MyISAM when your site got busier. Even single row updates would lock the whole table and slow things down to a crawl. Then you updated to InnoDB to get the benefit of row-level locking, but now the site is even slower than before. What gives? Here’s whats happening….

Using Block Dumps to Read Uncommited Transactions

My team and I still use old-style rollback segments for one of my client’s 10g production databases. We just never found the need to switch to automatic undo management. There are a number of 1GB rollback segments. They are that size because they need to be able to support large transactions. At the same time, we don’t want to have transactions bigger than 1GB as this is an OLTP system. For the past few weeks we’ve had a strange problem. One of the web calls would cause one of the rollback segments to become full by using 1GB of undo data.

Battle Against Any Guess

Greetings everyone. I would like to announce that last weekend the BAAG party was born. If you are tired of observing troubleshooting by guessing day by day, by day, by day, by … — join the forces of BAAG party. We can make a difference together! See you there.

Page 211 of 250« First...102030...209210211212213...220230240...Last »