decor
 

planetDB2 logo

Planet DB2 is an aggregator of blogs about the IBM DB2 database server. We combine and republish posts by bloggers around the world. Email us to have your blog included.

 

May 21, 2019


DB2Night Replays

The DB2Night Show #Z97: Why does the Db2 for z/OS Optimizer need a Data Sci

Presented by: Sheryl Larsen Worldwide Db2 Z Solutions Ambassador , BMC Software "The DB2Night Show #Z97: Why does the Db2 for z/OS Optimizer need a Data Scientist?" Replays available in WMV and M4V formats! 100% of our studio audience learned something!Sheryl discussed the new Db2ZAI product that enhances the Db2 optimizer. Watch the replay...

(Read more)
 

May 13, 2019


Data and Technology

Craig Mullins Presenting at Data Summit 2019

The world of data management and database systems is very active right now. Data is at the center of everything that modern organizations do and the technology to manage and analyze it is changing...

(Read more)
 

May 07, 2019


Henrik Loeser

Cloud-based FIPS 140-2 Level 4 crypto service

Locks, keys, and data security Yesterday, I got my hands on a FIPS 140-2 Level 4 cloud-based crypto service. If you are asking "what's that and what can I do with it?" you should continue to read....

(Read more)
 

May 03, 2019


Henrik Loeser

Your chatbot with Watson Discovery News

Some months back I introduced you to a barebone news chatbot. Today, with the updated tutorial to build a database-driven chatbot in place, I want to show you how to easily combine Watson Assistant...

(Read more)
 

May 02, 2019


Kim May

Mid-Atlantic Db2 LUW Meeting – Bethesda, May 7th

Thank you to the IBM Technical Team, Kay Groski and Warren Heising, for coordinating this terrific agenda and group of excellent speakers for the Mid-Atlantic Spring Db2 LUW Users Group Meeting! The...

(Read more)
 

April 30, 2019


Ember Crooks

Db2 Basics: Setting up a Command Line to Work with Db2

I’m a command line gal, and probably always will be. I doubt a GUI will tempt me away from the command line, though I do find myself enjoying using things like Jupyter Notebook to also access the databases I support.

Does Your Database Know Who You Are?

Read the rest
Use the Index, Luke

A Close Look at the Index Include Clause

Some database—namely Microsoft SQL Server, IBM Db2, and also PostgreSQL since release 11—offer an include clause in the create index statement. The introduction of this feature to PostgreSQL is the trigger for this long overdue explanation of the include clause.

Before going into the details, let’s start with a short recap on how (non-clustered) B-tree indexes work and what the all-mighty index-only scan is.

Recap: B-tree Indexes

To understand the include clause, you must first understand that using an index affects up to three layers of data structures:

  • The B-tree

  • The doubly linked list at the leaf node level of the B-tree

  • The table

The first two structures together form an index so they could be combined into a single item, i.e. the “B-tree index”. I prefer to keep them separate as they serve different needs and have a different impact on performance. Moreover, explaining the include clause requires making this distinction.

In the general case, the database software starts traversing the B-tree to find the first matching entry at the leaf node level (1). It then follows the doubly linked list until it has found all matching entries (2) and finally it fetches each of those matching entries from the table (3). Actually, the last two steps can be interleaved, but that is not relevant for understanding the general concept.

The following formulas give you a rough idea of how many read operations each of these steps needs. The sum of these three components is the total effort of an index access.0

  • The B-tree: log100(<rows in table>), often less than 5

  • The doubly linked list: <rows read from index> / 100

  • The table: <rows read from table>1

When loading a few rows, the B-tree makes the greatest contribution to the overall effort. As soon as you need to fetch just a handful of rows from the table, this step takes the lead. In either case—few or many rows—the doubly linked list is usually a minor factor because it stores rows with similar values next to each other so that a single read operation can fetch 100 or even more rows. The formula reflects this by the respective divisor.2


Note

If you are thinking “That’s why we have clustered indexes”, please read my article: Unreasonable Defaults: Primary Key as Clustering Key.


The most generic idea about optimization is to do less work to achieve the same goal. When it comes to index access, this means that the database software omits accessing a data structure if it doesn’t need any data from it.3

You can read more about the inner workings of B-tree indexes in Chapter 1, “Anatomy of an SQL Index of SQL Performance Explained.

Recap: Index-Only Scan

The index-only scan does exactly that: it omits the table access if the required data is available in the doubly linked list of the index.

Consider the following index and query I borrowed from Index-Only Scan: Avoiding Table Access.

CREATE INDEX idx
    ON sales
     ( subsidiary_id, eur_value )
SELECT SUM(eur_value)
  FROM sales
 WHERE subsidiary_id = ?

At first glance, you may wonder why the column eur_value is in the index definition at all—it is not mentioned in the where clause.


B-tree Indexes Help Many Clauses

It is a common misconception that indexes only help the where clause.

B-tree indexes can also help the order by, group by, select and other clauses. It is just the B-tree part of an index—not the doubly linked list—that cannot be used by other clauses.


The crucial point in this example is that the B-tree index happens to have all required columns—the database software doesn’t need to access the table itself. This is what we refer to as an index-only scan.

Applying the formulas above, the performance benefit of this is very small if only a few rows satisfy the where clause. On the other hand, if the where clause accepts many rows, e.g. millions, the number of read operations is essentially reduced by a factor of 100.


Note

It is not uncommon that an index-only scan improves performance by one or two orders of magnitude.


The example above uses the fact that the doubly-linked list—the leaf nodes of the B-tree—contains the eur_value column. Although the other nodes of the B-tree store that column too, this query has no use for the information in these nodes.

The Include Clause

The include clause allows us to make a distinction between columns we would like to have in the entire index (key columns) and columns we only need in the leaf nodes (include columns). That means it allows us to remove columns from the non-leaf nodes if we don’t need them there.

Using the include clause, we could refine the index for this query:

CREATE INDEX idx
    ON sales ( subsidiary_id )
     INCLUDE ( eur_value )

The query can still use this index for an index-only scan, thus yielding essentially the same performance.

Besides the obvious differences in the picture, there is also a more subtle difference: the order of the leaf node entries does not take the include columns into account. The index is solely ordered by its key columns.4 This has two consequences: include columns cannot be used to prevent sorting nor are they considered for uniqueness (see below).


“Covering Index”

The term “covering index” is sometimes used in the context of index-only scans or include clauses. As this term is often used with a different meaning, I generally avoid it.

What matters is whether a given index can support a given query by means of an index-only scan. Whether or not that index has an include clause or contains all table columns is not relevant.


Compared to the original index definition, the new definition with the include clause has some advantages:

  • The tree might have fewer levels (<~40%)

    As the tree nodes above the doubly linked list do not contain the include columns, the database can store more branches in each block so that the tree might have fewer levels.

  • The index is slightly smaller (<~3%)

    As the non-leaf nodes of the tree don’t contain include columns, the overall size of that index is slightly less. However, the leaf node level of the index needs the most space anyway so that the potential savings in the remaining nodes is very little.

  • It documents its purpose

    This is definitely the most underestimated benefit of the include clause: the reason why the column is in the index is document in the index definition itself.

Let me elaborate on the last item.

When extending an existing index, it is very important to know exactly why the index is currently defined the way it happens to be defined. The freedoms you have in changing the index without breaking any other queries is a direct result of this knowledge.

The following query demonstrates this:

SELECT *
  FROM sales
 WHERE subsidiary_id = ?
 ORDER BY ts DESC
 FETCH FIRST 1 ROW ONLY

As before, for a given subsidiary this query fetches the most recent sales entry (ts is for time stamp).

To optimize this query, it would be great to have an index that starts with the key columns (subsidiary_id, ts). With this index, the database software can directly navigate to the latest entry for that subsidiary and return it right away. There is no need to read and sort all of the entries for that subsidiary because the doubly linked list is sorted according to the index key, i.e. the last entry for any given subsidiary must have the greatest ts value for that subsidiary. With this approach, the query is essentially as fast as a primary key lookup. See Indexing Order By and Querying Top-N Rows for more details about this technique.

Before adding a new index for this query, we should check if there is an existing index that can be changed (extended) to support this trick. This is generally a good practice because extending an existing index has a smaller impact on the maintenance overhead than adding a new index. However, when changing an existing index, we need to make sure that we do not make that index less useful for other queries.

If we look at the original index definition, we encounter a problem:

CREATE INDEX idx
    ON sales
     ( subsidiary_id, eur_value )

To make this index support the order by clause of the above query, we would need to insert the ts column between the two existing columns:

CREATE INDEX idx
    ON sales
     ( subsidiary_id, ts, eur_value )

However, that might render this index less useful for queries that need the eur_value column in the second position, e.g. if it was in the where or order by clause. Changing this index involves a considerable risk: breaking other queries unless we know that there are no such queries. If we don’t know, it is often best to keep the index as it is and create another one for the new query.

The picture changes completely if we look at the index with the include clause.

CREATE INDEX idx
    ON sales ( subsidiary_id )
     INCLUDE ( eur_value )

As the eur_value column is in the include clause, it is not in the non-leaf nodes and thus neither useful for navigating the tree nor for ordering. Adding a new column to the end of the key part is relatively safe.

CREATE INDEX idx
    ON sales ( subsidiary_id, ts )
     INCLUDE ( eur_value )

Even though there is still a small risk of negative impacts for other queries, it is usually worth taking that risk.5

From the perspective of index evolution, it is thus very helpful to put columns into the include clause if this is all you need. Columns that are just added to enable an index-only scan are the prime candidates for this.

Filtering on Include Columns

Until now we have focused on how the include clause can enable index-only scans. Let’s also look at another case where it is beneficial to have an extra column in the index.

SELECT *
  FROM sales
 WHERE subsidiary_id = ?
   AND notes LIKE '%search term%'

I’ve made the search term a literal value to show the leading and trailing wildcards—of course you would use a bind parameter in your code.

Now, let’s think about the right index for this query. Obviously, the subsidiary_id needs to be in the first position. If we take the previous index from above, it already satisfies this requirement:

CREATE INDEX idx
    ON sales ( subsidiary_id, ts )
     INCLUDE ( eur_value )

The database software can use that index with the three-step procedure as described at the beginning: (1) it will use the B-tree to find the first index entry for the given subsidiary; (2) it will follow the doubly linked list to find all sales for that subsidiary; (3) it will fetch all related sales from the table, remove those for which the like pattern on the notes column doesn’t match and return the remaining rows.

The problem is the last step of this procedure: the table access loads rows without knowing if they will make it into the final result. Quite often, the table access is the biggest contributor to the total effort of running a query. Loading data that is not even selected is a huge performance no-no.


Important

Avoid loading data that doesn’t affect the result of the query.


The challenge with this particular query is that it uses an in-fix like pattern. Normal B-tree indexes don’t support searching such patterns. However, B-tree indexes still support filtering on such patterns. Note the emphasis: searching vs. filtering.

In other words, if the notes column was present in the doubly linked list, the database software could apply the like pattern before fetching that row from the table (not PostgreSQL, see below). This prevents the table access if the like pattern doesn’t match. If the table has more columns, there is still a table access to fetch those columns for the rows that satisfy the where clause—due to the select *.

CREATE INDEX idx
    ON sales ( subsidiary_id, ts )
     INCLUDE ( eur_value, notes )

If there are more columns in the table, the index does not enable an index-only scan. Nonetheless, it can bring the performance close to that of an index-only scan if the portion of rows that match the like pattern is very low. In the opposite case—if all rows match the pattern—the performance is a little bit worse due to the increased index size. However, the breakeven is easy to reach: for an overall performance improvement, it is often enough that the like filter removes a small percentage of the rows. Your mileage will vary depending on the size of the involved columns.

Unique Indexes with Include Clause

Last but not least there, is an entirely different aspect of the include clause: unique indexes with an include clause only consider the key columns for the uniqueness.

That allows us to create unique indexes that have additional columns in the leaf nodes, e.g. for an index-only scan.

CREATE UNIQUE INDEX …
    ON … ( id )
 INCLUDE ( payload )

This index protects against duplicate values in the id column,6 yet it supports an index-only scan for the next query.

SELECT payload
  FROM …
 WHERE id = ?

Note that the include clause is not strictly required for this behavior: databases that make a proper distinction between unique constraints and unique indexes just need an index with the unique key columns as the leftmost columns—additional columns are fine.

For the Oracle Database, the corresponding syntax is this:

CREATE INDEX …
    ON … ( id, payload )
ALTER TABLE … ADD UNIQUE ( id )
      USING INDEX …

Compatibility

Availability of INCLUDE

PostgreSQL: No Filtering Before Visibility Check

The PostgreSQL database has a limitation when it comes to applying filters on the index level. The short story is that it doesn’t do it, except in a few cases. Even worse, some of those cases only work when the respective data is stored in the key part of the index, not in the include clause. That means moving columns to the include clause may negatively affect performance, even if the above described logic still applies.

The long story starts with the fact that PostgreSQL keeps old row versions in the table until they become invisible to all transactions and the vacuum process removes them at some later point in time. To know whether a row version is visible (to a given transaction) or not, each table has two extra attributes that indicate when a row version was created and deleted: xmin and xmax. The row is only visible if the current transaction falls within the xmin/xmax range.7

Unfortunately, the xmin/xmax values are not stored in indexes.8

That means that whenever PostgreSQL is looking at an index entry, it cannot tell whether or not that entry is visible to the current transaction. It could be a deleted entry or an entry that has not yet been committed. The canonical way to find out is to look into the table and check the xmin/xmax values.

A consequence is that there is no such thing as an index-only scan in PostgreSQL. No matter how many columns you put into an index, PostgreSQL will always need to check the visibility, which is not available in the index.

Yet there is an Index Only Scan operation in PostgreSQL—but that still needs to check the visibility of each row version by accessing data outside the index. Instead of going to the table, the Index Only Scan first checks the so-called visibility map. This visibility map is very dense so the number of read operations is (hopefully) less than fetching xmin/xmax from the table. However, the visibility map does not always give a definite answer: the visibility map either states that that the row is known to be visible, or that the visibility is not known. In the latter case, the Index Only Scan still needs to fetch xmin/xmax from the table (shown as “Heap Fetches” in explain analyze).

After this short visibility digression, we can return to filtering on the index level.

SQL allows arbitrary complex expressions in the where clause. These expressions might also cause runtime errors such as “division by zero”. If PostgreSQL would evaluate such expression before confirming the visibility of the respective entry, even invisible rows could cause such errors. To prevent this, PostgreSQL generally checks the visibility before evaluating such expressions.

There is one exception to this general rule. As the visibility cannot be checked while searching an index, operators that can be used for searching must always be safe to use. These are the operators that are defined in the respective operator class. If a simple comparison filter uses an operation from such an operator class, PostgreSQL can apply that filter before checking the visibility because it knows that these operators are safe to use. The crux is that only key columns have an operator class associated with them. Columns in the include clause don’t—filters based on them are not applied before their visibility is confirmed. This is my understanding from a thread on the PostgreSQL hackers mailing list.

For a demonstration, take the previous index and query:

CREATE INDEX idx
    ON sales ( subsidiary_id, ts )
     INCLUDE ( eur_value, notes )
SELECT *
  FROM sales
 WHERE subsidiary_id = ?
   AND notes LIKE '%search term%'

The execution plan—edited for brevity—could look like this:

               QUERY PLAN
----------------------------------------------
Index Scan using idx on sales (actual rows=16)
  Index Cond: (subsidiary_id = 1)
  Filter: (notes ~~ '%search term%')
  Rows Removed by Filter: 240
  Buffers: shared hit=54

The like filter is shown in Filter, not in Index Cond. That means it was applied at table level. Also, the number of shared hits is rather high for fetching 16 rows.

In a Bitmap Index/Heap Scan the phenomenon becomes more obvious.

                  QUERY PLAN
-----------------------------------------------
Bitmap Heap Scan on sales (actual rows=16)
  Recheck Cond: (idsubsidiary_id= 1)
  Filter: (notes ~~ '%search term%')
  Rows Removed by Filter: 240
  Heap Blocks: exact=52
  Buffers: shared hit=54
  -> Bitmap Index Scan on idx (actual rows=256)
       Index Cond: (subsidiary_id = 1)
       Buffers: shared hit=2

The Bitmap Index Scan does not mention the like filter at all. Instead it returns 256 rows—way more than the 16 that satisfy the where clause.

Note that this is not a particularity of the include column in this case. Moving the include columns into the index key gives the same result.

CREATE INDEX idx
    ON sales ( subsidiary_id, ts, eur_value, notes)
                  QUERY PLAN
-----------------------------------------------
Bitmap Heap Scan on sales (actual rows=16)
  Recheck Cond: (subsidiary_id = 1)
  Filter: (notes ~~ '%search term%')
  Rows Removed by Filter: 240
  Heap Blocks: exact=52
  Buffers: shared hit=54
  -> Bitmap Index Scan on idx (actual rows=256)
       Index Cond: (subsidiary_id = 1)
       Buffers: shared hit=2

This is because the like operator is not part of the operator class so it is not considered to be safe.

If you use an operation from the operator class, e.g. equals, the execution plan changes.

SELECT *
  FROM sales
 WHERE subsidiary_id = ?
   AND notes = 'search term'

The Bitmap Index Scan now applies all conditions from the where clause and only passes the remaining 16 rows on to the Bitmap Heap Scan.

                 QUERY PLAN
----------------------------------------------
Bitmap Heap Scan on sales (actual rows=16)
  Recheck Cond: (subsidiary_id = 1
             AND notes = 'search term')
  Heap Blocks: exact=16
  Buffers: shared hit=18
  -> Bitmap Index Scan on idx (actual rows=16)
       Index Cond: (subsidiary_id = 1
                AND notes = 'search term')
       Buffers: shared hit=2

Note that this requires the respective column to be a key column. If you move the notes column back to the include clause, it has no associated operator class so the equals operator is not considered safe anymore. Consequently, PostgreSQL postpones applying this filter to the table access until after the visibility is checked.

                 QUERY PLAN
-----------------------------------------------
Bitmap Heap Scan on sales (actual rows=16)
  Recheck Cond: (id = 1)
  Filter: (notes = 'search term')
  Rows Removed by Filter: 240
  Heap Blocks: exact=52
  Buffers: shared hit=54
  -> Bitmap Index Scan on idx (actual rows=256)
       Index Cond: (id = 1)
       Buffers: shared hit=2

A Close Look at the Index Include Clause” by Markus Winand was originally published at Use The Index, Luke!.

 

April 29, 2019


Data and Technology

Craig Mullins to Deliver Database Auditing Webinar – May 15, 2019

Increasing governmental and industry regulation coupled with the need for improving the security of sensitive corporate data has driven up the need to track who is accessing data in corporate...

(Read more)
 

April 27, 2019


Henrik Loeser

Db2: SQL-based explain and printed acccess plan

Vote for this Db2 idea This Friday in Munich, I gave a talk about the new native JSON functions in Db2 at the German Db2 user group (DeDUG) meeting. To speed up queries and to enforce uniqueness or...

(Read more)
 

April 26, 2019


Robert Catterall

Db2 12 for z/OS Statistics Profiles: Just What the Optimizer Ordered

Here is an interesting story for you: not long ago, an analytics-type query was executed on a Db2 for z/OS system that had recently been migrated to Db2 12. The query was cancelled after it had run for 23 hours. A DBA noticed that there was a row for a table targeted by the query in SYSIBM.SYSTABLES_PROFILES in the Db2 catalog. He ran RUNSTATS for the table, specifying USE PROFILE so that the utility would pick up the options specified in the aforementioned statistics profile. The DBA observed...

(Read more)

DB2Night Replays

The DB2Night Show #Z96: Db2 for z/OS Latest News and Future Directions

Presented by: Jeff Josten Distinguished Engineer, IBM SVL "The DB2Night Show Z96: Db2 for z/OS Latest News and Future Directions" Replays available in WMV and M4V formats! 97% of our studio audience learned something!Jeff gave a summary of some of the latest news and deliveries from Db2 for z/OS development. Watch the replay...

(Read more)
 

April 24, 2019


Ember Crooks

Interesting Issue with /tmp on a Db2 Server

I learn something new every day. The times I’m most surprised about what I learn is when it happens to be something pretty fundamental about how Db2 uses resources.

Environment

This situation happened on an AIX environment I’m mentoring someone to build.… Read the rest


Henrik Loeser

Updated tutorial: Database-driven chatbot

If you want to build a chatbot that gets its content from a database, there is a good news. The existing tutorial “Build a database-driven Slackbot” was just updated to adapt to latest features of...

(Read more)
 

April 22, 2019


Craig Mullins

Db2 Application Testing Considerations

Testing application programs XE "testing application programs"  is a discipline unto itself and there are many considerations and nuances to be mastered to be able to test software appropriately. This blog post will not go into a lot of depth regarding testing practices, other than to highlight the important things to keep in mind to assure optimal performance of your Db2...

(Read more)
 

April 12, 2019


DB2Night Replays

The DB2Night Show #214: ALL ABOUT IDUG Charlotte NC June 2-6

@IDUGDb2 Special Guests: Mike Inman, Dustin Ratliff, Mike Winer IDUG CPC Volunteers ALL ABOUT IDUG Charlotte NC, June 2-6, 2019 State of the Db2 Universe Study Winners Announced! 100% of our audience learned something!Mike, Dustin, and Mike gave us the inside scoop on what to expect at IDUG this June. NOTICE! There will be tech sessions on Db2 LUW V11.5! Plus SIGs, Ed Seminars, Certification Testing, Keynotes, IBM Champion sessions, z/OS...

(Read more)
 

April 09, 2019


Kim May

Free Hands-on IDAA Class Announced – July 18 & 19, Columbus, Ohio

Join us for this new and improved for 2019 class to be delivered by IBM Gold Consultant Frank Fillmore. Contents include IDAA v7 early experiences, best practices, and v5 to v7 migration tips....

(Read more)
 

April 01, 2019


Kim May

Conference & Conference & Conference Oh My!!

The buildup and push for the Think Conference was manic. The “EXCITEMENT!!” seemed to come from a small group of IBM marketing folks and the focus on attendance numbers (tough to confirm...

(Read more)
 

March 31, 2019


Robert Catterall

A Case Study: Implementing a Db2 for z/OS Implicit Trusted Connection

I've been interested in the role and trusted context features of Db2 for z/OS for a long time (I posted a two-part blog entry on the topic back in 2011). Theory is nice, but what about practice? Recently, I had an opportunity to assist a DBA in implementing implicit trusted connection functionality in his Db2 for z/OS environment (more on the implicit part in a moment). Today I'll share some of what the DBA and I learned through that endeavor. First, the backstory: the DBA's...

(Read more)
 

March 29, 2019


DB2Night Replays

The DB2Night Show #213: Db2 LUW Native Encryption - What to Expect!

@IBM_Paul_Bird Special Guest: Paul Bird STSM IBM Toronto Lab Db2 LUW Native Encryption: What to Expect when you're Expecting to Encrypt! 100% of our audience learned something!Paul gave us an excellent presentation about Db2 LUW Native Encryption that covered Performance, Operational, and Availability considerations. Mind your keys! Watch and learn...

(Read more)
 

March 28, 2019


DB2Night Show News

29 March 10am CDT: Db2 LUW Native Encryption with guest Paul Bird, IBM

New shows for Season #10 of The Db2Night Show are scheduled! Encryption! IDUG! IBM Breaking News! Problem Determination! Here are the highlights and registration links:

...
 

March 26, 2019


Craig Mullins

IBM Releases Db2 12 for z/OS Function Level 504

Early in March 2019, IBM announced the latest and greatest new function level, 504 (FL504), for Db2 12 for z/OS. For those of you not paying attention, starting with Version 12, IBM has moved to a continuous delivery model and has been releasing new functionality regularly. This means that new capabilities are rolled out periodically in what IBM calls function levels. The first few new function...

(Read more)

Ember Crooks

DB2 Basics: Beyond Just Taking a Backup – Backup Performance, Utilities, and More!

While I’ve covered this topic in detail, and blogged about a specific backup performance problem, I’ve never talked about this at the basics level.

What is a Backup?

A backup is a binary image of the entire Db2 database.… Read the rest

 

March 25, 2019


Henrik Loeser

Running Db2 Developer-C as Docker container

Container: Db2 the easy way Last week I wanted to start testing some new Db2 features without going through the steps of installing that Db2 version. I turned to my local Docker installation, issued...

(Read more)
 

March 19, 2019


Ember Crooks

SQL Differences Between Db2 and Informix

I have been working with Informix from a user perspective recently. I learned about some of the SQL differences and developed a greater empathy for developers in the process. CTE Support is covered, along with comparing the date and time handling syntax.
 

March 18, 2019


DB2Night Replays

Db2Night Show #z95: Db2 Batch System Design for High Performance

Presented by: Neal Lozins Softbase "The DB2Night Show #Z95: Db2 Batch System Design for High Performance" Replays available in WMV and M4V formats! 94% of our studio audience learned something!Neal described the issues, challenges and techniques for designing optimal batch applications. Watch the replay...

(Read more)
 

March 14, 2019


Ember Crooks

SQL That Meant Well: Where Functions are Applied

Not only was this delete running unreasonably slow – it was also causing lock timeouts on the MEMBER table while running because of the slowness. This post contains application specific details that you don’t need to understand the underlying concept here, which applies across many SQL statements in the real world.
 

March 13, 2019


Triton Consulting

Expand your DB2 Knowledge – DB2 for z/OS Master Class 2019

There’s still time to book onto the week-long Db2 for z/OS Master Class offered by IBM’s Db2 for z/OS Development team. The UK class will be taking place at IBM Huxley in Hampshire and will be led by IBM Distinguished … Continue reading → The post Expand your DB2 Knowledge...

(Read more)
 

March 10, 2019


DB2 Guys

Use your Bathroom more Effectively

Whether you think about it an in-home escape out of your hectic day or just someplace to clean up, the lavatory is one place in your house everybody is bound to go to. Taking advantage of a small house is all the time a good suggestion, and turning bigger grasp bogs into spa-like getaway rooms is a rising pattern.

The next are some rest room adorning concepts for any toilet, irrespective of how a lot or how little you need to spend.

Make Easy Issues Depend

One of many best methods to replace your bathtub cupboards and add pizzaz is to swap out the previous hardware for brand new. You’ll have no drawback discovering an abundance of designs at retailers, which suit your type and finances. Earlier than you fall in love with a brand new pull, knob or deal with, you should definitely measure the space between holes to ensure the swap requires nothing greater than a screwdriver, and contemplate the end on the hinges to forestall clashing.

Add Some Ambiance

Spa parts—together with showers that double as steam rooms, Jacuzzis and decadent soaking tubs, mini-bars and warming trays for towels—are all widespread lavatory adorning concepts these days. “Individuals are spending extra time of their baths as a result of it’s a retreat from busy life,” says Susan Marinello, Principal Design Director. “It is sensible that they need the spa components that assist them to loosen up and rejuvenate.”

Though the sky’s the restrict, you may have an expensive grasp toilet even on a price range. “There are some actually low-cost tips you should use to occur a spa setting,” says inside designer Leslie Harris. “All lights needs to be on a dimmer, and a sound system and even an iPod for those who can’t wire for audio system goes a great distance in direction of creating a soothing setting.” You too can set up electrical heating pads below the flooring materials. “You’ll be able to simply warmth a three-foot by three-foot pad in entrance of the self-importance or bathe and actually improve the toilet expertise,” Marinello explains.

In fact, don’t overlook that little luxuries go a great distance. Place contemporary flowers and scented candles in your counter tops, fill up on great soaps and physique scrubs and some super-fluffy towels. Pure and soothing blues, greens, and gold are good. Touches of nature go a good distance, as nicely; add a window backyard or grasp framed images of your dream mountain getaway.

The post Use your Bathroom more Effectively appeared first on Decorate and Fun!.

 

March 09, 2019


DB2 Guys

Stylish Living Room

Magnificence Seems to be Straightforward

Elegant residing rooms show effective design with out showing flashy. And it’s tougher than it sounds. This lounge within the house of Washington, D.C. designer Skip Sroka reaches the head of stylish conventional design with light curves on the window therapies and furnishings. Each chairs and the couch have fantastically rolled arms in addition to refined curves on the again. The home windows are adorned with curved Roman shades in a damask tone-on-tone that underlie easy pleated silk panels. All collectively, the curves convey a shapely magnificence that ties the room collectively. That is the essence of sentimental adorning. The coffered ceiling and quiet palette proceed the understated attraction

Basic Strains

This hearth view of designer Skip Sroka’s Washington D.C. front room reveals extra of his secrets and techniques to creating a sublime area. The gold-leaf mirror above the hearth is ornamented with a Greek-key motif, the grandfather of traditional patterns. (Assume the alternative of classy.) The mirror does greater than introduce traditional strains, nevertheless. It additionally swings out to disclose a flat-screen TV. This type of cleverly hid hard-working operate supplies another clue to the that means of stylish adorning. Effectivity. (Apple merchandise’ effectivity makes them probably the most elegant of their business. The identical guidelines apply to each inside and industrial design.) The whole hearth presentation is refined via the symmetrical stability of the mirror between a pair of vintage sconces

Beautiful and Gentle Dwelling Room

Making the best adorning choice generally means doing nothing in any respect. When a front room just like the one on this East Hampton home is blessed with lovely French doorways and an abundance of sunshine, a sensible designer is aware of to depart nicely sufficient alone: Preserve the home windows undressed. Designer Larry Laslo did simply that. He additionally enhanced the structure’s airiness with a monochromatic palette of soppy pearl and sand with darkish wooden accents.

The post Stylish Living Room appeared first on Decorate and Fun!.

 

March 08, 2019


Ember Crooks

SQL That Meant Well: Applying Conditions in the Subquery vs the Outer Query

This is a new series that has been percolating in my head for a while. When I help clients with SQL, we’re often adding (or removing) indexes to help SQL performance. It has been said (though not by me) that SQL re-write is obsolete because the Db2 Optimizer will take care of that.… Read the rest


DB2 Guys

Mirror Decorating Ideas

Mirrors are one of many essential mandatory objects in home adorning. We searched some strategies which will mirror you in all of the exact strategies. Whether or not or not you’re looking for a model new addition to your bar cart or a glitzy contact in your mattress room, incorporating a mirror is a ought to.

Paired With a Facet Desk

We love the idea of pondering previous the dresser as regards to mattress room mirrors. Paired in opposition to your facet desk, a mirror creates a styled look and helps to reflect the lamp’s mild.

Hung Above a Mattress

No headboard? No disadvantage! A mirror makes an necessary substitute and helps to open up your room. Even in case you will have a headboard, hanging a mirror above it creates a gallery impression.

Rested In opposition to a Wall

An oversize mirror rested in the direction of your wall creates the final phrase, laid-back however luxe look. While you don’t want a set of three, the bigger the mirror, the upper for this styling trick.

Used Previous the Wall

For many who favor the look of mirrors, suppose previous the wall. Mirrored furnishings is a chic addition, notably when paired a set of mirrored frames!

Saved Typical

Usually, it’s OK to stick with customized. You probably cannot go incorrect hanging a mirror above your mantel, notably when your partitions are painted black.

The post Mirror Decorating Ideas appeared first on Decorate and Fun!.

 

March 07, 2019


DB2 Guys

Elegant Living Room Ideas

Magnificence with an Edge

So can a front room be elegant and edgy ? The Honolulu residence of designer Marion Philpotts Miller suggests the reply is sure. Sure stately furnishings like a grand piano are fixtures of finery, and music-loving Miller is a fan. However she’s an equally avid supporter of visible arts together with these with a contemporary bent. The lounge’s lavender pod chandelier provides an edgy layer of complexity to the room’s design, making it as fascinating as it’s elegant.

Sterling Design

Dove grey and a focus to element occur serene sophistication in the lounge of this Connecticut residence overlooking Lengthy Island Sound. “I didn’t need a beachy house so we went with darkish flooring and traditional particulars,” says the proprietor, architectural designer Louise Brooks. Farrow & Ball’s “Skimming Stone” is painted on the partitions, whereas the wooden comes clear within the venerable paint firm’s “All White.” Silver-gray cocktail and aspect tables choose up the thread of shade from the room’s gray-and-white striped  Elizabeth Eakins rug, whereas the furnishings stays calm in white upholstery materials. Even the equipment on the fireside wall’s cabinets are pared down for significance. Most notable is the pair of vintage lanterns on the center cabinets.

Fashionable Combine

Who higher than furnishings designer Bob Williams to grasp the fashionable combine? In the lounge of his house in Hickory, North Carolina, the cofounder of furnishings producer Mitchell Gold + Bob Williams pairs his new designs with classic favorites from the mid-century. His eye for high quality is revealed in his treasured outdated Lucite chair, Eames-style white leather-based armchair, and Frank Gehry cardboard chair, all of which mingle together with his personal clean-lined designs. Conventional toile draperies from Duralee and ice-blue partitions set off the elegant combine.

The post Elegant Living Room Ideas appeared first on Decorate and Fun!.

decor