Monday, November 12, 2012

Enabling and Disabling query logging in Teradata


Database query logging (DBQL) is an optional feature in Teradata through which we can track processing behavior of database by logging user activity. User activity can be logged in various level namely object, sql text, steps, explain etc. one can also set limit to the length of query text to be logged.
since this is resource consuming task that database has to perform on each activity, on should assess impact on database performance before enabling it in various level.

Query logging can be enabled on user using its account name. Every user created in database has its account name (account string) assigned while user creation, though account string can be assigned to a user or group of user manually.

Account string of a user can be verified by querying "dbc.accountinfo" view or better edit profile to check account string.

select * from dbc.accountinfo where username =’username’


The DBQL can be enable for specific user using their account string by below command

begin query logging with explain,objects, sql on all account=(' $M$BUSI$S$D$H')

in the above command query logging will be enabled for  objects, sql text and explain  on all user having account ‘$M$BUSI$S$D$H' .  There are few more detail option for query logging is available namely step logging, xml explain, summery logging.  The text size of sql text can be limit by limit clause as below. Here 0 means unlimited whereas any positive integer will limits to its value.


begin query logging with explain,sql limit sqltext=0 on all account=(' $M$BUSI$S$D$H')

Query logging can be disable with end query logging command as show below.

end query logging with explain,objects, sql on all account=(' $M$BUSI$S$D$H')


DBQL can be enabled for all users irrespective of their account string by below command

Begin query logging with objects, sql limit sqltext=0 on all


Finally DBQL rules can be verified by querying "dbc.dbqlrules" view.

select * from dbc.dbqlrules

Sunday, November 4, 2012

Where does TD store transient journal?


Transient Journal (TJ) is an area of space in the DBC database which is used primarily for storing of roll-back/undo  information during inserts/deletes/updates on a tables. 

TJ require perm space and is stored in "dbc.transientjournal". This special type of table can grow beyond dbc's  perm space limit until the whole system runs out of perm space.

It is good practice to backup Transient Journal regularly and delete to enhance query and load performance.

Saturday, November 3, 2012

Few differences between Global Temporary Table and Volatile Table

 Global Temporary tables (GTT) :

  • Table Definition is stored  into Data Dictionary.
  • Data is stored in temp space.
  • GTT data is active upto the session ends, but table definition will remain there in Data dictionaly untill is is dropped  using Droptable statement.
  • secondry Index can be created on Global Temporary table.
  • Stats can be collected on GTT.
  • CHECK or BETWEEN constraints, COMPRESS column and DEFAULT and TITLE clause are supported by Global Temporary table.
  • In a single session 2000 Global temporary table can be materialized.


Volatile Temporary tables (VTT) :

  • Table Definition is stored in System cache.
  • Data is stored in spool space.
  • VTT data and table definition both are active only upto session ends.
  • secondry Index can not be created on Global Temporary table.
  • stats cannot be collected on VTT.
  • CHECK or BETWEEN constraints, COMPRESS column and DEFAULT and TITLE clause are not supported by GTT.
  • In a single session 1000 Volatile temporary table can be materialized.
  • VTT does not support default value for a column while creating a table.