Skip to content

DDL

  1. Uniqueness constraint must be NOT NULL. UPI/USI can have NULLable columns
  2. If a JI has CURRENT_DATE/TIMESTAMP, ALTER TO CURRENT deletes/inserts all rows
  3. SHOW QUALIFIED \<dml\> on JI expands the CURRENT_DATE to the actual values used
  4. Join Index:
    1. PPI only on uncompressed, non VO JI, UPI only on single table
    2. Yes: coll stat, NUSI No: USI, Arc (marked as invalid on restore)
    3. Row compression is done on rows that are INSERTed in the same request
    4. Base table: No: triggers, Fload, Mload
    5. To create VOPI, use ORDER BY clause and PI clause.
    6. if base table columns are compressed they are compressed in JI too
  5. Hash Index: BY (default PI of base table, AMP local), ORDER BY (value-ordered) | ORDER BY HASH (must be same as BY columns)
  6. CREATE TABLE AS
    1. doesn’t copy FK, Triggers and JI.
    2. Copies PJ or Fallback attributes for perm tables only
    3. When overriding an index, all indexes must be respecified
    4. creating from sub-query doesn’t copy table level attributes or indexes. No column level attributes like compress, default value are copied by default.
    5. column attributes can be specified as parameter list when copying table as subquery, but data types must be changed in subquery.
    6. When adding PK or Unique constraint, must add NOT NULL attribute
  7. Default PI selection: PK > First Unique constraint (Col then table) > (DBSControl #53 == ‘N’ ? NOPI : First column)
  8. PI Dist candidates: Distinct values, Max Rows/Val, Max NULL, Typical Rows/val
  9. DB/USER level options: FALLBACK, JOURNAL TABLE, DATEFORM,
  10. Inherited child user attrs: first acct id, spool, temp
  11. Default user attrs: perf group: $M, pass attrs: dbc.syssecdefaults
  12. Triggers: No BEFORE STMT, no data changing SQL in BEFORE triggers.
    1. order: BEFORE| AFTER, ORDER, create timestamp
  13. DELETE DATABASE/USER doesn’t drop JI, HI or PJ
  14. DROP DATABASE/USER only succeeds if it is empty
  15. Table DDL CHECKSUM: stored in CI, Rows not updated in-place, checksums are written with a separate IO, higher overhead
  16. Queue tables need to have first col as QITS TIMESTAMP(6) NOT NULL DEFAULT
  17. CREATE ERROR TABLE.. FOR.. used with MERGE|INS-SEL.. LOGGING ERRORS [WITH LIMIT].
    1. Must be MULTISET, Can be created for CP but as NOPI
    2. 13 ETC_ columns ETC_DBQL_QID, ETC_DMLTYPE, ETC_ErrorCode, ETC_FieldId
    3. Doesn't capture all errors. Ensure has same PI.
  18. ALTER TABLE works by rebuilding cylinder at a time => no fragmentation and no TJ

Volatile/GTT/Trace Tables

  1. No: RI, PJ, SI/JI/HI, CPPI, RLS
  2. VT/GTT: LOG NO => no transient journaling (default YES)
  3. Volatile tables
    1. No: CHECK, column default, col titles, MVC, named indexes
    2. Yes: refer in macro and views
    3. DELETE DATABASE/USER doesn’t drop volatile tables
    4. use same namespace as perm tables. can’t create VT if Perm Tbl exists
  4. GTTs
    1. Yes: CREATE/DROP index, COLL STAT, ALTER, LOG and TJ, PPI/NOPI
    2. can survive system restart
    3. DROP TEMP TABLE drops instance. DROP TABLE drops def and local instance. DROP TABLE … ALL drops def and all instances
    4. DEL DATABASE/USER drops GTT tables, but fails if there are instances (use ALL)
    5. Can DROP index on instance and not drop index on base
    6. stats on base table define columns. stats on instance actually collect stats.
    7. Can’t define stats if already materialized.
  5. Global Temp Trace Tables: Used as debugging mechanism in external routines
    1. No: PI, SET, FALLBACK, Indexes, PPI, NOPI, col default, INS/DEL/UPD (except DEL ALL), Join with other tables, Temporal
    2. First 2 cols VPROC_ID BYTE(2) and SEQUENCE INTEGER are reserved
    3. Enable using: SET SESSION FUNCTION TRACE USING 'xxx' FOR TABLE UDF_Trace
    4. UDF writes using FNC_Trace_Write_DL or FNC_Trace_Write

Referential Integrity

  1. Soft RI: WITH NO CHECK OPTION
  2. Standard RI
    1. Maintains index sub-table, hashed by FK value (same as parent UPI or USI)
    2. Adding RI on a populated table invalidates violations, but data remains available (including INS/DEL/UPD). Cannot add new invalid rows.
      1. Creates <tbl>_n (n=0,4,8…) error table.
      2. INSERT into parent table doesn’t revalidate a row, but if a child row is later inserted or updated it is marked as valid.
      3. RI violations will cause only the statement to fail (no auto rollback)
      4. PK or FK columns cannot be compressed
  3. Batch RI (WITH CHECK OPTION)
    1. No index sub-table
    2. Adding RI on a populated table will cause ALTER to fail if there are any violations
    3. Allows cascading AFTER triggers:INSERT child or UPDATE/DELETE parent
    4. ROT: Use only for small table or when RI isn’t likely to be violated. Rollback can be expensive for statement that modify large number of rows
  4. Reference Index states
    1. Unresolved: when creating circular FK. Auto fixed when all FK created
    2. Inconsistent: Parent or child restored. Childs go to inconsistent.
      1. ALTER TABLE child DROP INCONSISTENT REFERENCES
      2. No rows data modifications are allowed
      3. (ARC) REVALIDATE REFERENCES
    3. Invalid: Caused by rollforward or rollback or adding new RI or REVALIDATE REFERENCE
      1. ALTER TABLE DROP FOREIGN KEY… ADD FOREIGN KEY

Authorization & Privileges

  1. 3 types: Automatic (creator), Explicit (granted) and Implicit (Ownership, not stored in DD).
  2. GRANT ALL includes only the privileges held by grantor WITH GRANT OPTION
  3. Roles:
    1. Cannot GRANT to role descendents (ALL)
    2. Role privilege (CREATE/DROP) cannot be granted to PUBLIC or other Roles
    3. WITH ADMIN OPTION on roles allow grantee to drop/grant/revoke roles to others.
    4. ANSI: Only single active role. No WITH GRANT OPTION to roles
  4. REVOKE cannot revoke object level privileges if GRANT was at DB level, but doesn’t fail.
  5. REVOKE GRANT/ADMIN OPTION FOR <priv>, to revoke just the WITH GRANT/ADMIN
  6. REVOKE ALL will not revoke INDEX and REFERENCES explicit privileges
  7. CREATE TABLE/INDEX also grants COLLECT/DROP STATS
  8. SQL SECURITY CREATOR, DEFINER, INVOKER, OWNER (need CREATE OWNER PROCEDURE)
  9. DEFINER (default): owner/creator privileges during compile, owner during execution
  10. Nested views: privileges of creator checked at create time, for owner checked at run-time.
  11. UPDATE/DELETE commands with WHERE clause require SELECT as well
  12. DEL/DROP DB/USER: Cannot drop entire hierarchy, only objects within specified DB/USER
  13. CREATE USER grants CREATE/DROP USER/DATABASE automatic rights to creator
  14. Column level privileges: SEL/UPD/REF/INS
  15. GRANT .. TO ALL <db> allows new childs to inherit previously granted rights to parent
    1. ALL DBC is same as PUBLIC
  16. Dropping GRANTOR does not revoke granted access rights
  17. To GRANT/REVOKE LOGON from specific host id, need EXEC access on dbc.LogonRule
  18. SHOW STATISTICS without VALUES requires only ANY privilege, whereas VALUES clause requires SELECT access to underlying objects. OVERRIDE SELECT CONSTRAINT for RLS tables
  19. Trusted connection allow Teradata to check privileges, query/access logging against end-user IDs instead of middle-tier ID
    1. GRANT CONNECT THROUGH <trusted-user> [WITH TRUST_ONLY] TO <app-user>
    2. SET QUERY_BAND PROXYUSER/PROXYROLE

Row Level Security

  1. Security Classification Category has a name and a list of valid labels
  2. CREATE CONSTRAINT <name> <data-type> VALUES (<name:value>) INS/SEL/DEL/UPD SYSLIB.<func>
    • Data-type: SMALLINT => hierarchical, BYTE(n <=32) => compartment
    • 4 UDF enforce SELECT, INSERT, UPDATE and DELETE security checks
    • Sample UDF rules:
      • select session >= row or session superset of row
      • insert row gets session labels
      • updates select + are reclassified using user’s level.
      • Deletes are not permitted unless at the lowest level or NULL
  3. GRANT CONSTRAINT DEFINITION|ASSIGNMENT for defining|using constraints
  4. BEGIN LOGGING DENIALS… FOR CONSTRAINT log row if security constrained on the object is not defined for the session. If defined but lacks required value then no logging is done.
  5. Security is bypassed for users with OVERRIDE CONSTRAINT privilege
  6. Compound statement (INS-SEL)
    1. All tables must have same security constraints
    2. constraints are copied from source, unless user has override privilege
  7. All RLS tables within a vIew must have same security constraints

PPI

  1. No PPI for compressed Join Indexes
  2. if there is NO RANGE partition, DROP WITH DELETE actually moves rows to it
  3. Alternate to using CASE_N -> RANGE_N(HASHBUCKET(HASHROW(COL_EXPR)) MOD nn)
  4. For partition elimination on TIMESTAMP casted to DATE, AT clause must be specified, so the expression becomes deterministic. Otherwise date is dependent on session timezone
  5. Can’t alter partitioning expression unless stats on PARTITION is dropped
  6. Use DELETE instead of ALTER to drop partitions for lengthy op (maybe because of SI), since DELETE takes WRITE lock whereas ALTER will take EXCLUSIVE lock
  7. MLPPI:
    1. most likely eliminated or less granular levels at higher level.
    2. ordering is less imp if many data blocks at combined level.
    3. For non-empty tables, only RANGE_N can be added/removed only at highest level
    4. if ALTER changes # of partitions, it can be done only on level 1
    5. SPE can occur with CURRENT_DATE, :var, certain built-in function. Only CURREN_DATE allows caching of plans (TD12)
  8. Can ALTER to add/remove partition only at the ends and if RANGE_N is used.
  9. Can ALTER to modify multiple levels, but number of non-level 1 parts cannot be changed
  10. ROT Overpartitioning is when blocks/AMP/Partition < 10
  11. ALTER TO CURRENT ON PARTITION BY CASE_N(EXP_DATE = CURRENT_DATE, NO CASE) will perform worse than on PARTITION BY CASE_N(EXP_DATE >= CURRENT_DATE, EXP_DATE < CURRENT_DATE) because the former will require scanning both partitions to move rows. The latter only the first partition needs to be scanned for moving rows
    1. UNKNOWN partition is always scanned
    2. Preferable to use contiguous timelines instead of gaps when using CASE_N
  12. Excess partitions allocated to:
    1. The only single partition overriding ADD
    2. MLPPI and only CP doesn’t have ADD, then CP
    3. MLPPI, no ADD on CP and at least 1 row partition, then 10 to CP and 1st no-ADD RP
    4. MLPPI, only RP with no ADD, no-ADD RP in level order
    5. MLPPI all have ADD, 1st partition overridden

NOPI

  1. Random number generator within PE and AMP distributes rows among all AMPs
  2. Lowest hashbucket value (20 bits) is selected for AMP, remaining (44) bits used for uniqueness.
  3. hashbucket values are generally same for all rows unless all uniqueness values are used up then it moves onto next hashbucket value
  4. INSERT SELECT uses the AMP value of the SELECT
  5. No: Upsert, Merge, mload, PPI, identity, PJ, HI, SET, queue/error table
  6. Data skewing for NOPI and CP tables:
    1. when restored on more amps, data still gets copied to the same hashbucket (=> AMP)
    2. when restored on fewer amps, two hashbuckets may map to same AMP
    3. Reconfig: with fewer AMPs, multiple hash-buckets will go to a same AMP
    4. Down AMP when number of AMPs in cluster > 2

Columnar

  1. Only one level in MLPPI can be columnar
  2. Three primary types: CPNoPI, CPPA, CPPI (+CPUPI)
    1. CPPA: When using PA columns: single AMP access, local access for Joins, faster GROUP BY
    2. CPPI: Vertically partition frequently/rarely used columns.
      • Slight increase in space due to 2+ row headers
      • Uses 32-bit rowhash and 32-bit uniqueness (unlike 20-bit rowhash and 44-bit uniqueness for CPPA and CPNoPI)
  3. Complex update for all columns that are not ROW FORMAT
  4. Rows are only logically deleted and recorded in the hidden partition
    • except when all columns are in ROW FORMAT, then it's physically deleted
    • space for LOBs, SI, HI and reference indexes are always reclaimed
  5. No: sync read, temporal, vt, gt, fload, upsert/merge/mload (since no PI). Yes: identity
  6. Use INSERT-SELECT to load data
    • Only for CPNoPI: Use HASH BY [RANDOM| …] to reduce data skew
    • Use LOCAL ORDER BY in increase compressibility
  7. Special INSERT (CP) SELECT (NOPI) optimization to avoid spool
  8. CP JI must be single table, non compressed, must have ROWID, no AJI, but can be sparse
  9. Reduces IO, so if workload is CPU bound then CP may not be a good fit
  10. Use INTO for adding columns: ALTER TABLE x ADD storeid INT INTO store_name
  11. If # of available contexts < # of column partitions being selected, multiple sub-row partitions will be created using available contexts and then all will need to be consolidated
  12. COLLECT STATS ON PARTITION#Ln is allowed only for column partition level and collects compression info rather than row ratio of each column partition.
  13. INSERT-SELECT into CP (vs CP+RP) only table from NOPI can avoid sorting rows.
  14. INSERT-SELECT may not spool source even when access lock on the source if source needs to be read only once (that is if there are enough contexts to write all columns at once)
  15. Auto-compression isn’t carried to spool, but user compression is. => Spool requirements are usually higher (than base CP table)
  16. DDL:
    1. Grouped columns are combined into 1 column partition CT T ((c1 INT, C2 INT))
    2. ALL BUT columns are in single column partition with auto compress
    3. Without all but, unspecified columns are in single partition
  17. ROT: Have column partitions at first level then row partitions.
    • Otherwise INSERTs are slow because it requires searching through several combined partitions to find correct container that is end point.
  18. ROT: Use COLUMN format when columns are narrow and many duplicates. Use ROW format when columns are wide and not many duplicates
  19. ROT: INSERTs are costly because auto-compression and row needs to be split into multiple CP. If the source table is not a NOPI table, it may be scanned multiple time depending on # of contexts
  20. ROT: Number of read contexts are (inversely) affected by DB size. Write contexts are not.
  21. ROT: If # of column contexts are constantly running out increase PPICacheThrP

Admin

  1. ASE variables: &S session, &D date, &H hour, &T (HHMISS), &I (host ID,&S, req#), &L logon time (useful when a group of users share same id/pw)
  2. If query runs for multiple AMPUsage intervals, entire time is recorded during first entry.
  3. Suggested account strings:
    1. PG_&S: multi-sess multi-req (=>load utilities) and single-sess tactical.
    2. PG_&I: single-sess non-tactical
  4. Profile: Acct strings, Default DB, Password, Spool/Temp space
  5. Password: SpecChar, Digits, RestrictWords, Expire, MinChar, MaxLogonAttempts, Reuse
    1. SpecChar: Username?(Y/N), alpha?(Y/R), mixed case?(Y/R), special char?(Y/N/R)
  6. Dropping a profile doesn’t resets user profile to NULL, but resets user attributes to default
  7. Changes to User account-list and database take effect at next login user sets them.
  8. begin/end logging [denials] [with text] on [first|last|each] <op> [by <user>] on <obj>
    1. specifies obj, user, freq, text (never/always/denials)
    2. log written before stmt can run, hence very resource intensive
  9. begin query logging [with <log>] [limit <lim> [and <lim>]] on all | user | (appl)
    1. <log>: none,all,explain(expensive),objects(many rows), sql, stepinfo, xmlplan(TD13+)
    2. <lim>: SQLTEXT/SUMMARY/THRESHOLD
      1. SQLTEXT[=n] (default 200 if no option, 10K if no value)
      2. SUMMARY: n1 n2 n3. summary information every 10 minutes
      3. THRESHOLD: if < n (sec) then same as SUMMARY else default row
    3. SUMMARY/THRESHOLD metrics: CPUTIME, ELAPSETIME (0.01 sec), ELAPSEDSEC, IOCOUNT,
    4. DBQL: \<TD13, can’t specify ALL users and specific USER
    5. DBQL TD13+: hierarchy APPL>User+Acct>User>Acct>All
    6. DBQL TD14.10+: USECOUNT (includes stats), STATSUSAGE (stale stats)
    7. ROT: Use acct strings to decide which SQLs to capture in DBQL
    8. ROT: Multi-Sess mutti-req => DB utilities => predictable, single-sess nontactical => unpredictable, single-sess tactical => high vol optimized.
      1. Detailed logging for 1&2 above and summary for #3