Specialized IT Services focused on Data Management | Speak with Us 877-634-9222
Author: Craig Mullins
Recently I was reading through some posts on a database-related blog or mailing list (actually, right now I can't remember which one it was). The conversation I was reading was in response to this question: "Does the number of columns or size of the row matter in terms of performance?"
Let’s say I have a table A which has 500 columns. Out of those 500 columns only 5 columns have been defined as not nullable and the rest have been defined as NULLS allowed.
This blog will compare the use of VARCHAR to DB2 compression when you are building your DB2 databases. Visit to learn more.
You should really do the investigative work required to find out the real level of support for DB2 V11 that is in the GA version of the tool. Read more.
Are any of the DB2 unload utilities able to include the column names in the same file as the unload output data? Read on to discover the answer.
One of the long-standing, troubling questions in DB2-land is when to use VARCHAR versus CHAR. The high-level advice for when to use VARCHAR instead of CHAR is for larger columns whose length varies considerably from row-to-row. Basically, VARCHAR should be used to save space in the database when your values are truly variable. In other words, if you have a 10-byte column, it is probably not a good idea to make it variable… unless, of course, 90% of the values are only one…
We want to examine CHAR data but return only those where the entire data consists only of numbers. For example, can we write a query like this?
If you are using DB2 V7 or higher, consider using scrollable cursors. With scrollable cursors, you can move directly to the rows you want without having to FETCH every other row returned by the cursor.
A null represents missing or unknown information at the column level. If a column “value” can be null, it can mean one of two things: the attribute is not applicable for certain occurrences of the entity, or the attribute applies to all entity occurrences, but the information may not always be known.
DSNTEP2 is an application program that can be used to issue DB2 dynamic SQL statements. It is sometimes referred to as “Batch SPUFI” because it allows you to submit SQL in batch similar to how SPUFI allows online SQL execution. The following sample JCL demonstrates the capability of DSNTEP2 to issue DCL, DDL, and DML dynamically.