IBM DB2

Overview

Signals reads conversion and customer data straight from a DB2 database on a schedule and sends the columns you nominate to your ad platforms.

Reading it directly means there is no file job to maintain and nothing to go stale between runs. Signals reads only; nothing is written back.

You can point it at a table, or at a query. The query path is what you want when the shape Signals needs does not match anything you already have.

DB2 is one name over more than one product. DB2 for Linux, UNIX and Windows and DB2 for z/OS share most of the SQL surface and part company over how the connecting account is created: on z/OS the authorization ID is defined in RACF or another external security manager, while privileges stay inside DB2 and are granted with GRANT unless the access control authorization exit has been installed to move them out as well. What follows describes DB2 for Linux, UNIX and Windows. On z/OS the connection fields are the same, but take the account creation from whoever administers your security manager rather than from this page.

Supported destinations

Destinations supported by IBM DB2

Category	Supported
Offline Conversions	Google Offline Conversions API Google Store Sales LinkedIn Offline Conversions API Meta Offline Conversions API OpenAI Offline Conversions API Snapchat Offline Conversions API TikTok Offline Events API
Lead Conversions	Google Enhanced Conversions for Leads LinkedIn Leads Conversions API Meta Conversions API for CRM Snapchat Leads Conversions API TikTok CRM Integrations
Custom Audience	Google Customer Match Meta Custom Audience Snapchat Custom Audience TikTok Custom Audience

Authentication

In Studio, open Sources, find the Database category, and click the IBM DB2 tile.

Field	What it is	Where to find it
Authentication Name	Your own label for this set of credentials.	You choose it. Name it for the database it belongs to.
Username	The database user Signals connects as.	Created as an operating system user on the database host, then granted read access inside DB2.
Password	The password for that user.	Set when the user was created.

DB2 tables live inside a schema, so a table name on its own may be ambiguous. Qualify it if the database holds the same table name in more than one schema.

Caution

Create a dedicated read-only user for Datahash rather than reusing an application or administrator account. It keeps the connection working when someone rotates a password, and it stops the connection seeing more than it needs. Enter the password on the Datahash connection screen only.

DB2 for Linux, UNIX and Windows has no CREATE USER statement. Authentication is delegated to a security plugin, and the default plugin checks the operating system’s user registry on the database host, so the account has to exist as an operating system user before DB2 accepts it at all. Creating it is a host administration task rather than a database one, and where an LDAP plugin has been configured instead, the account belongs in that directory. That step is where a DB2 setup usually stalls, because nothing on the connection form hints at it.

One GRANT covers the read, and it names both the schema and the table:

GRANT SELECT ON TABLE analytics.conversions TO USER datahash;

Keep the USER keyword. The same statement grants to users, groups and roles, and the keyword is what tells DB2 which of the three a name refers to instead of leaving it to resolve a name that may exist as more than one of them. A schema-level form, GRANT SELECTIN ON SCHEMA analytics TO USER datahash, covers tables added to the schema after the grant runs and hands over every other table in the schema along with them; it is not present on every release, so confirm it against yours before writing it into a runbook. What to avoid either way is DATAACCESS on the database, the shortcut that gets taken when a per-table grant looks fiddly. It is not a read privilege: on a database it carries insert, update, delete, load and execute alongside select, so an account given it to save a few lines can write to the data it was only meant to read.

Configuration

Instance Setup

Select the Integration Type, which is the kind of data your records hold. Offline Events is the common choice. Give the instance a name, then choose the table path or the query path. On either path you enter the Host Name, Port and Database Name, and then either the Table Name or a SQL query.

The integration type decides the columns Signals expects and which destinations the connection can feed, so it is worth settling before anyone models the data. It also decides which file format you get on the next screen.

Port, TLS and naming the target

50000 is the port a DB2 instance listens on unless someone has changed svcename. TLS is a second listener rather than a setting on the first: ssl_svcename gives it a port of its own, 50001 by convention, and DB2COMM has to include SSL before the instance offers it. The two ports are not interchangeable in either direction: a client without SSL configured on its own side fails the handshake against the SSL listener rather than falling back to cleartext. Where your policy governs which path this connection takes, ask your Datahash representative which port to enter rather than choosing between them from the server configuration alone.

One instance commonly holds several databases behind that single port, and Database Name is the only field separating them. A name that belongs to a different database on the same instance connects successfully and reads whatever is there, which surfaces later as a table that cannot be found rather than as a connection problem.

Enter the table as SCHEMA.TABLE, in the case DB2 stored it. Unquoted identifiers are folded to uppercase when the object is created, so a table created as Conversions is held as CONVERSIONS; SELECT TABSCHEMA, TABNAME FROM SYSCAT.TABLES shows both parts as they actually are.

Table path

Enter the connection details including the table name, then complete the setup. The name is typed rather than picked from a list, so it has to match the database exactly.

Query path

Enter the connection details without the table name, then write the query. Preview the results before finishing, and read the column names in the output rather than just the row count: a query that runs but returns the wrong names will fail silently once the connection is live.

Manage instance

One instance reads one table or query for one integration type. To read another, add another instance from the Manage existing instance table. To change an existing one, open it from there, click the edit option in the menu to the top right, update the fields and click Finish.

File format and schema

Download the file format from the setup screen and shape the table to it. The column names are what Signals matches on, so a column that has been renamed or cased differently is not recognized and the row it belongs to is dropped rather than reported.

On the query path the same rule applies to the column aliases your query returns. Aliasing to the expected names is the usual way to reconcile data you cannot or should not restructure.

Data & identifiers

Personal identifiers are normalized and hashed before they are sent to a destination.

Best practices

• Use a dedicated read-only user scoped to the data Datahash reads, rather than an application account.
• Prefer the query path with explicit column aliases over pointing at a raw table. It lets your team change the underlying model without breaking the connection.
• Have whoever administers HADR confirm the standby accepts readers at all, because one does not by default. Reads on the standby are switched on by setting the DB2_HADR_ROS registry variable to ON on it, which is a restart of the instance rather than a statement, and a standby left without it refuses the connection outright rather than serving stale rows. Where it is on, uncommitted read is the only isolation level the standby honors, so a client asking for anything stricter is turned away instead of quietly downgraded. Replay of DDL or of a maintenance operation can additionally open a replay-only window, and what that costs turns on DB2_HADR_ROS_AVOID_REPLAY_ONLY_WINDOW. With that variable OFF, which is the whole of the behavior on any release predating 11.1.4.4, where it does not exist at all, the standby disconnects the readers it already has for the length of the window and holds new ones off, and a scheduled read meets that as an intermittent failure with nothing wrong at either end. Ask the same administrator which way it is set on your standby.
• Clean the data in the view or query: lowercase email, phone in E.164, no stray whitespace. Hashing a badly formatted value produces a hash that will never match.
• Rotate the password periodically and update the connection afterwards.

Troubleshooting & FAQ

The connection times out rather than reporting bad credentials. That points at reachability rather than authentication. Confirm the host is exposed, the port is open, and any firewall or allow list permits the connection.

Credentials are rejected. Check the user can read the data from a client of its own first. Most failures here are permissions rather than typos.

The table name is rejected. It is typed rather than selected, so it has to match exactly. DB2 uppercases unquoted identifiers.

A table you can read from another client is reported as an undefined name. An unqualified table name is completed with the CURRENT SCHEMA special register, which starts every session as the authorization ID that connected. CONVERSIONS entered for the DATAHASH account therefore resolves to DATAHASH.CONVERSIONS, which nobody created, while the table meant by it sits in ANALYTICS. DB2 answers with SQL0204N and names the qualified form it looked for, and that qualified form is the diagnosis: read the schema in it, not the table. Qualify the name in the Table Name field and inside any query on the query path. A table that does exist but is out of the account’s reach fails with a privilege error instead, so an undefined name points at resolution rather than at the grant.

The query previews correctly but nothing is delivered. The column names it returns do not match the expected schema. Alias them to the names in the downloaded file format.

It was working and stopped. The password may have been changed or the user disabled. A dedicated service user avoids this.