DBAs and database professionals have been aware of the pros and cons of compressing data for years. The traditional argument goes something like this: with compression you can store more data in less space, but at the cost of incurring CPU to compress the data upon insertion (and modification) and decompress the data upon reading it. Over time, the benefits of compression became greater as compression algorithms became more robust, hardware assist chips became available to augment compression speed, and the distributed model of computing made transmitting...
Wednesday, 31 July 2013
Friday, 26 July 2013
Top Ten Most Common DB2 Performance Problems
Posted on 13:13 by Unknown
PEBCAK The number one cause of DB2 performance problems today, as always, is Problem Exists Between Chair And Keyboard! Poorly coded SQLMany performance problems can be traced back to inappropriately coded SQL Code it correctly from the beginning and tune what is already out there. Improper indexingOptimize performance via indexing by workload, not by object. Bad program designCoding DB2 SQL for Performance in your application programs from the outset can eliminate many future...
Posted in best practices, BIND, database design, DB2 Developer's Guide, performance, SQL
|
No comments
Friday, 19 July 2013
DB2 Locking, Part 17: In Conclusion
Posted on 10:44 by Unknown
Today's blog post concludes our multi-part series on DB2 for z/OS locking and concurrency. We have touched on a great many aspects of locking in this series. Such an in-depth, technical topic as DB2 locking can be difficult to master, but doing so can deliver a more clear understanding of how DB2 operates and how your programming and design decisions impact not only your application, but also the entire DB2 subsystem. A Couple Additional Locking Ideas and ThoughtsBefore concluding this series, here are a few more guidelines and thoughts...
Monday, 15 July 2013
DB2 Locking, Part 16: Skipping Uncommitted Inserts
Posted on 09:28 by Unknown
DB2 10 for z/OS introduces a new technique for concurrency. As we have discussed previously in this series on DB2 locking, one of the most troublesome problems for DB2 performance analysts is reducing timeouts and lock suspensions.The CONCURRENTACCESSRESOLUTION parameter can be used to specify a concurrent access resolution option to use for statements in a package when binding your application program.There are two options. The first, USECURRENTLYCOMMITTED, indicates that DB2 can use the currently committed version of the data for applicable scans...
Tuesday, 9 July 2013
DB2 Locking, Part 15: Tackling Timeout Troubles
Posted on 13:46 by Unknown
Many shops battle with locking issues and frequently, the cause of performance issues can be traced back to locking issues, more specifically, lock timeout issues. When you experience a timeout, it means that another process holds a lock on the data that you are trying to modify. You may experience timeout troubles as the dreaded -911 SQLCODE. Timeouts are different than most performance issues because the job or users receiving the -911 SQLCODE is usually not the source of the problem. Instead, the jobs causing the problem typically continue to...
Saturday, 6 July 2013
DB2 Locking, Part 14: Using the LOCK TABLE Statement
Posted on 15:42 by Unknown
We continue the series on DB2 locking today with a look at the SQL statement: LOCK TABLE .You can issue the LOCK TABLE statement in your application programs to raise the lock granularity to the table (actually, table space) level. Doing so means that you will not need to take lower level locks (at the page or row level, whichever is in effect for the table space in question). Issuing a LOCK TABLE in a program can make sense in certain, specific circumstances. Consider using the LOCK TABLE statement to control the efficiency of locking in programs...
Monday, 1 July 2013
DB2 Locking, Part 13: Optimistic Locking
Posted on 08:12 by Unknown
Continuing our series on DB2 locking, let's look into a relatively recent development -- optimistic locking...IBM added improvements for optimistic locking techniques in DB2 9 for z/OS. What is optimistic locking? Sometimes referred to as optimistic concurrency control, optimistic locking is basically just what it sounds like. We are optimists and think that usually we will be the only ones with interest in the data. In other words, when optimistic locking is implemented you are assuming that most of the time there will be no other programs...
Subscribe to:
Posts (Atom)
