Abstract

It is sometimes necessary to run a simple UPDATE statement through most or all of the rows in a large table. This cannot be done as a single statement in a logged database without adversely impacting the system or affecting users. The table cannot be exclusively locked while it is in use, so an excessive number of row locks would likely result, causing shared memory growth. It might also fail with “Long Transaction Aborted” due to logical log consumption over the allowed threshold.

This article provides an Informix Stored Procedure Language (SPL) function to commit a sensible number of rows per transaction, and describes a particular use case when you need to move smart blobs to another sbspace.

See also these previous articles that provide functions “sp_dbload” and “sp_dbdelete” to achieve the same objective with INSERT and DELETE:

LOAD and UNLOAD functions

Stored Procedure for Mass Delete

Content

Examples in this article were produced using the provided “stores_demo” database in a Docker container from informix-dockerhub with Informix Dynamic Server (IDS) updated to 14.10.FC11.

Two functions will be described:

  • sp_dbupdate – Safe mass update avoiding “long transaction aborted” and excessive locks
  • sp_sbrewrite – Rewrite all smart blobs for a specified column after redefining their location

It’s best to see how they are used for context before we look at the code. In an actual scenario, we needed to move all smart blobs to a new dbspace after deleting obsolete rows. There is no “repack shrink” for blob spaces, and we wanted to release space, so the only solution was to create a new smaller smart blob space and move them all across.

For demonstration in this article, this was set up:

Copy to Clipboard


Smart blobs are not logged by default, meaning they would not be replicated, etc., so either specify that at the sbspace or table level. We have done both above, whereas you would normally do one or the other.

You do not need a PUT clause for BLOB or CLOB columns that will use the default sbspace held in configuration parameter SBSPACENAME, as could have been configured in our example with:

Copy to Clipboard


Before moving blobs, we first need to redefine where they should in future should be located:

Copy to Clipboard


If the database were not logged, we could have done this to move blobs to the new dbspace:

Copy to Clipboard
  • “LOCOPY(contents)” on its own would use system default storage characteristics.
  • Informix removes the old copy of the blob automatically once it is no longer referenced.

See the documentation on LOCOPY here.

However, a single UPDATE statement is not practical for a large logged table, so a function has been written to do any such update safely, committing a sensible number of rows per transaction. For example, any outstanding in-place alter would be eliminated by this:

Copy to Clipboard


That returns:

Copy to Clipboard


For our smart blob copy, we could do this:

Copy to Clipboard
  • Note that two quotes represent a literal quote.
  • The current database needs specifying as “$dbname” in that context.
  • We can and should skip rows where the smart blob is null anyway.

To make it easier, the following wrapper function performs a smart blob column rewrite, returning the same output:

Copy to Clipboard


Whichever of those methods was used, we could then drop the original smart blob space without loss of data:

Copy to Clipboard


Both functions were installed in separate database “oninit”, where we place general purpose functions. It does not need to be in every database where it might be used, but can be called from a central store of your choice. Listings and explanations follow.

Copy to Clipboard


See comments in the article on the similar sp_dbdelete function. Also note:

  • Tables names containing special characters or mixed case should be handled if contained in double quotes with DELIMIDENT set in the environment.
  • If a user supplies a whole SQL statement to specify key values, only a single SELECT works with DECLARE, so this is secure against SQL injection exploits.
Copy to Clipboard

Conclusion

The functions in this article provide a safer way to update a large number of rows in a table instead of using a single UPDATE statement, and a specific convenient way to move smart blobs to a different sbspace.

Disclaimer

Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.

Contact Us

If you have any questions or would like to find out more about this topic, please contact us.

Author