A client has an update that they must run (unfortunately) which updates ~830,000 rows, setting one column

equal to the other (two column table). On their develo pment environment this was taking roughly twenty seconds to perform. However, on their soon-to-be production environment it was taking roughly 45 minutes. Explain plans were checked, trace files examined, and not much popped up except that the production machine was attempting larger I/Os during the update and was consequently taking much longer. Comparing the initialization parameters betwee n production and development showed the exact same parameters, except that the u pcoming production box was using a 16k block size and development was using a 4k block size. There was one other difference, which was that the upcoming production server wa s 64-bit and the development server was 32-bit. In order to make sure everything was the same, I created a fresh instance on the 64-bit production server with a block size of 4k, exported the objects from the instance with the 16k block siz e, and imported them. The final result: When the update was run against the 16k blocksize DB, it took 45 minutes. Against the 4k blocksize DB on the same box with the same parameters and the same FS mounts, it took 2 minutes 20 seconds. I even took it a step further to see if we could squeeze any more performance ou t of it. Setting FILESYSTEMIO_OPTIONS= SETALL (instead of none) I was able to get t he update down to 1.5 minutes. Turning off DB_BLOCK_CHECKING (not recommended) I was able to get it down to 10 seconds. By going from a 16k blocksize to a 4k blocksize with all other things being equa l, we experienced roughly a twenty times improvement. We shaved off even more ti me setting FILESYSTEMIO_OPTIONS = SETALL. And then we changed DB_BLOCK_CHECKING, a parameter Oracle documentation says only adds a 1 to 10% overhead depending o n concurrency of DML, which made the update 6 times faster alone. The final result was a 270 times improvement over the original. To be fair, I also tried setting the FILESYSTEMIO_OPTIONS and DB_BLOCK_CHECKING the same on the 16k blocksize instance, which resulted in the update taking 30 m inutes as opposed to 45. The results were better, but the 4k blocksize database still won by 180 times. What s more, all queries both large and small performed the same or better than in production, and a test insert of 100,000 rows went from 20 seconds on the 16k b locksize to 3 seconds on the 4k. Conclusion Honestly, there are no final conclusions yet. Like shows a 400 pound man slimming up to 150 pounds, e it definitely shows that changing only blocksize ore thorough analysis will help get to the core of atever the case, it definitely shows us to keep an stone unturned! a weight loss commercial that results may not be typical . Whil can have a profound effect, m why it had such an effect. Wh open mind in tuning. Leave no

NOTE: There is one interesting outcome that I ve observed: on the 16k block size d atabase, the UPDATE statement performs full table scans against FILE$. On the 4k blocksize database, it performs range scans using the FILE_I2 index. This only makes a difference of about 1 consistent get per execution, but it is worth noti ng.