Lead Database Administrator
Ember is always curious and thrives on change. Working in IT provides a lot of that change, but after 18 years developing a top-level expertise on Db2 for mid-range servers and more than 7 years blogging about it, Ember is hungry for new challenges and looks to expand her skill set to the Data Engineering role for Data Science. With in-depth SQL and RDBMS knowledge, Ember shares both posts about her core skill set and her journey into Data Science. Ember lives in Denver and work from home

Posts:

Stagingprop – the basics

I realized today that I haven’t done a post on the basics of stagingprop. All the pieces are there somewhere in the info center, and I love the info center once you’ve got the basics down, but I remember how confusing stagingprop was when I first started out, even though I had a major expert on the topic to ask questions of.… Read the rest

Continue reading »

DBClean – staglog

This is part of a series focusing on the details of each item that needs to be pruned in a Commerce database.

STAGLOG

What is it?

Staglog is a table in the staging database that records changes in data. Staging triggers on all stagingprop tables write to it when there is a change to any of those tables.… Read the rest

Continue reading »

DB2 for Commerce IDs

So the easy thing to do on Commerce build is to use your DB2 instance owner for everything related to the database. But that’s not really the best choice. It’s almost always the choice I see when a DBA was not involved with the architecture or build of a Commerce system.… Read the rest

Continue reading »

When to Backup your DB2 database

Ok, so there are several good reasons for Backing up your Commerce DB2 database

  1. After Commerce Instance Creation
  2. As required by your overall ongoing backup and recovery strategy
  3. Before a FixPack(DB2 or Commerce) or Feature Pack(Commerce)
  4. After a FixPack(DB2 or Commerce) or Feature Pack(Commerce)
  5. Before any task that requires change of a lot of data – such as first time pruning, explicit executions of delete statements or update/insert statements that will affect more than one table.
Read the rest Continue reading »

Build Tip – DB2 Backups

Schedule DB2 backups starting immediately after instance creation – the most common time that restores are needed is during the build process. Of course the most common cause for needing a restore is human error, but that’s something that is important to protect against during build.… Read the rest

Continue reading »

Build Tip – Database Naming

Just a quick tip. When building Commerce environments, select a different database name for each environment (Stage, Prod, etc), even if they are on different database servers. This will help you ensure that you(or developers or whoever else accesses the databases) never do something in the wrong environment.… Read the rest

Continue reading »

dbclean and data pruning intro

One of the most important things for performance of Commerce databases is the proper use of dbclean and data pruning.

It is a simple fact of life for OLTP databases that the same database with less data will perform better. This is especially true of Commerce databases, and even before a site has gone live, I try to have data pruning planned, scripted, and running on a regular basis.… Read the rest

Continue reading »

What is a “Volatile” table?

There is a flag that can be set on DB2 tables to mark them as “Volatile”. But not everyone knows what a volatile table is or what this does, so I thought I’d write a quick post on it.

A true volatile table is one that is used only for transient data – data that is put into tables and then quickly removed, meaning that a table marked as volatile could have zero rows one minute, 40,000 the next, and then back to zero.… Read the rest

Continue reading »