Translating concepts from SQL Server to DB2 -
i'm hoping catch eye of experience in both sql server , db2. thought i'd ask see if comment on these top of head. following list of features sql server, i'd db2 well.
configuration option "optimize ad hoc workloads", saves first-time query plans stubs, avoid memory pressure heavy-duty one-time queries (especially helpful extreme number of parameterized queries). - if - equivalent db2?
on similar note, equivalents sql server configuration options auto create statistics, auto update statistics , auto update statistics async. fundamental creating , maintaining proper statistics without causing overhead during business hours?
indexes. mssql standard index maintenance reorganize when fragmentation between 5 - 35%, rebuild (technically identical drop & recreate) when on 35%. importantly, mssql supports online index rebuilds keeps associated data accessible read / write operations. similar db2?
statistics. in sql server standard statistics update procedure useless in larger db's, sample ratio far low. there equivalent update statistics x fullscan in db2, or functioning consideration?
in mssql, rebuild index operations recreate underlying statistics, important consider maintenance operations in order avoid overlapping statistics maintenance. best method statistics updates in larger db's involves targeting them on per-statistic basis, since full table statistics maintenance can extremely heavy when example few of dozens of statistics on table need updated. how relate db2?
show execution plan invaluable tool analyzing specific queries , potential index / statistic issues sql server. best similar method use db2 (explain tools? or else)?
finding bottlenecks: sql server has system views such sys.dm_exec_query_stats , sys.dm_exec_sql_text, make extremely easy see run, , resource-intensive (number of logical reads, instance) queries need tuning, or proper indexing. there equivalent query in db2 can use instantly recognize problems in clear , easy understand manner?
all these questions represent big chunk of many of problems sql server databases. i'd take know-how, , translate db2.
i'm assuming db2 linux, unix , windows.
configuration option "optimize ad hoc workloads", saves first-time query plans stubs, avoid memory pressure heavy-duty one-time queries (especially helpful extreme number of parameterized queries). - if - equivalent db2?
there no equivalent; db2 evict least used plans package cache. 1 can enable automatic memory management package cache, db2 grow , shrink on demand (taking account other memory consumers of course).
what equivalents sql server configuration options auto create statistics, auto update statistics , auto update statistics async.
database configuration parameters auto_runstats
, auto_stmt_stats
mssql standard index maintenance reorganize when fragmentation between 5 - 35%, rebuild (technically identical drop & recreate) when on 35%. importantly, mssql supports online index rebuilds
you have option of automatic table reorganization (which includes indexes); trigger threshold not documented. additionally have reorgchk
utility calculates , prints number of statistics allow decide tables/indexes want reorganize manually. both table , index reorganization can performed online read-only or full access.
is there equivalent update statistics x fullscan in db2, or functioning consideration? ... best method statistics updates in larger db's involves targeting them on per-statistic basis, since full table statistics maintenance can extremely heavy when example few of dozens of statistics on table need updated.
you can configure automatic statistics collection use sampling or not (configuration parameter auto_sampling
). when updating statistics manually using runstats
utility have full control on sample size , statistics collect.
show execution plan invaluable tool analyzing specific queries , potential index / statistic issues sql server. best similar method use db2
you have both gui (data studio, data server manager) , command-line (db2expln
, db2exfmt
) tools generate query plans, including plans statements in package cache or executing.
finding bottlenecks: sql server has system views such sys.dm_exec_query_stats , sys.dm_exec_sql_text, make extremely easy see run, , resource-intensive (number of logical reads, instance) queries need tuning
there extensive set of monitor procedures, views , table functions, e.g. monreport.dbsummary()
, top_dynamic_sql
, snap_get_dyn_sql
, mon_current_sql
, mon_connection_summary
etc.
Comments
Post a Comment