DB2 – Differences Between EDU and Thread

database-enginedb2db2-luwprocessterminology

In DB2, there is this command that shows active EDUs (engine dispatchable units):

db2pd  -edus

There are two fields in the respective output: EDU ID and TID.

According to this db2pd page from the DB2 knowledge center, each is defined as follows:

EDU ID: The unique identifier for the engine dispatchable unit (EDU). Except on Linux operating systems, the EDU ID is mapped to the thread ID. On Linux operating system the EDU ID is a DB2 generated unique identifier

TID: Thread identifier. Except on Linux operating systems, the thread ID is the unique identifier for the specific thread. On Linux operating systems, this is a DB2 generated unique identifier

I wanted to know what is considered EDU or thread on a Linux/Unix operating system? Are they the same? What is the difference?

Best Answer

EDU is an abstraction over the underlying OS scheduling unit, a sort of a surrogate key assigned to whatever is doing actual work in the OS. If the OS has true threads, distinct from processes, such as Windows, an EDU will map to a thread. On modern Linux, which doesn't have threads but rather lightweight processes (LWPs), an EDU would map to one of such LWPs and the thread ID value would be artificial.

On some operating systems there is an extra level of abstraction in the form of separately managed user and kernel threads; in such cases an EDU will be mapped to a distinct kernel thread ID (KTID) in addition to the user TID.

Related Solutions

What do you call something that’s not the primary key

User terms surrogate key and natural key for primary key as a variant.

Surrogate Key:

Surrogate keys are keys that have no “business” meaning and are solely used to identify a record in the table. Such keys are either database generated (example: Identity in SQL Server, Sequence in Oracle, Sequence/Identity in DB2 UDB etc.) or system generated values (like generated via a table in the schema).

Natural Key:

Keys are natural if the attribute it represents is used for identification independently of the database schema. What this basically means is that the keys are natural if people use them example: Invoice-Numbers, Tax-Ids, SSN etc.

Surrogate Keys vs Natural Keys for Primary Key

DB2 LUW Timestamp differences in versions

Depending on its precision, a TIMESTAMP value may have fractional seconds. For literals, the precision is defined by the presence of a fractional part after seconds, as well as the number of digits in the fractional part. For columns, the precision is defined as an optional parameter after the name of the type in the column definition. For instance:

SomeColumn TIMESTAMP(9)

defines the column as a timestamp with nanosecond precision (9 digits after the decimal point). (As you have SQL Server background, you can compare this to the SQL Server datetime2 type, which also has optional precision.)

For reference, see IBM Knowledge Center - Datetime values.

It looks likely that the column in question is defined differently between the development environment and production, the development definition being TIMESTAMP(0) (no fractional seconds) and the production definition TIMESTAMP(6) (or simply TIMESTAMP, which means the same).

That explains why your developer never has to specify fractions of a second in the development environment – because the column's values cannot possibly have fractional seconds. At the same time, she may have to specify timestamps with a fractional part in the production environment because the column type there allows fractions of a second in the values and some timestamps apparently do have fractional parts.

Best Answer

Related Solutions

What do you call something that’s not the primary key

DB2 LUW Timestamp differences in versions

Related Question