The DB2 landscape is changing quickly, and sometimes things can quietly sneak in before you even realize it. Maybe you have heard IBMers talking about JSON support in DB2, but have you heard about the mobile DB2 access and DB2 RESTful API that is now available for DB2 for z/OS?
This week we continue our theme of improving application performance by reducing the number of calls to DB2. In addition to using DB2 techniques, we look at programs that retrieve more data than they really need, retrieve data sooner than it is needed, and retrieve the same data multiple times.
Sometimes we forget. It isn’t so much getting older (I hope) but more that we continue to get busier and busier. With the rush to pick up and handle the new tasks that are thrown our way we sometimes miss the basics. Application design that takes into account performance is one of those basics...
Most relational tuning experts agree that the majority of performance problems with applications that access DB2 are caused by poorly coded programs or improperly coded SQL. A great deal of time is spent on tuning your SQL but how much time are you spending tuning or conducting performance reviews o
What’s the main difference between single-row and multi-row inserts? Simply the performance. If you are inserting many rows in a loop via a single-row insert, you call DB2 for every single row, which means you spend some time for the communication with the DB2.