1 juliandyke.com Bitmap Index Internals Julian Dyke Independent Consultant Web Version © 2005...

1

juliandyke.com

Bitmap Index Internals

Julian Dyke

Independent Consultant

Web Version

© 2005 Julian Dyke

2 © 2005 Julian Dykejuliandyke.com

Agenda

Introduction Bitmap Row Sources Internal Structures Bitmap Index DML Conclusion


Introduction


Bitmap Indexes Introduced in Oracle 7.3

Originally intended for columns with Low cardinality (few distinct values) Little or no DML activity

Often used in DSS environments Useful for ad-hoc queries where predicates are not known

in advance


Bitmap Index Properties Bitmap indexes

Must be non-unique Include NULL values (B*Tree indexes do not) Maximum 30 columns (B*Tree indexes max 32 columns) Can be locally partitioned (8.1.5 and above) Cannot be globally partitioned Can be function-based indexes (built-in or user-defined) Can be IOT secondary indexes (9.2 and above) Can be created on global temporary tables Cannot be compressed Cannot be reversed


Bitmap Indexes

CREATE TABLE property (

property_code NUMBER,bedrooms NUMBER,receptions NUMBER,garages NUMBER

);

CREATE BITMAP INDEX index1 ON property (bedrooms);CREATE BITMAP INDEX index2 ON property (receptions);CREATE BITMAP INDEX index3 ON property (garages);

SELECT property_code FROM propertyWHERE bedrooms = 4AND receptions = 3AND garages = 2

For example


Logical Operations Bitmaps can be combined using the logical operations AND,

OR , NOT.

A B A AND B A OR B NOT A

0 0 0 0 1

0 1 0 1 1

1 0 0 1 0

1 1 1 1 0

Oracle also implements a MINUS operation internally A MINUS B is equivalent to A AND NOT B


Multicolumn Bitmap Indexes Bitmap indexes can be defined for more than one column

CREATE BITMAP INDEX i1 ON t1 (c1,c2);

Can be used for queries such as

SELECT * FROM t1 WHERE c1 = 0;SELECT * FROM t1 WHERE c1 = 0 AND c2 = 0;

However for queries such as

SELECT * FROM t1 WHERE c2 = 0;

there is apparently no equivalent to INDEX (SKIP SCAN) Consider creating two indexes and allowing Oracle to perform join dynamically

CREATE BITMAP INDEX i1 ON t1 (c1);CREATE BITMAP INDEX i2 ON t1 (c2);


Bitmap Row Sources

10

© 2005 Julian Dykejuliandyke.com

Bitmap Row SourcesOperation Version

BITMAP INDEX (SINGLE VALUE) 7.3.2

BITMAP INDEX (RANGE SCAN) 7.3.2

BITMAP INDEX (FULL SCAN) 7.3.2

BITMAP INDEX (FAST FULL SCAN) 9.0.1

BITMAP AND 7.3.2

BITMAP OR 7.3.2

BITMAP MINUS 7.3.2

BITMAP MERGE 7.3.2

BITMAP KEY ITERATION 7.3.2

BITMAP CONVERSION TO ROWIDS 7.3.2

BITMAP CONVERSION COUNT 7.3.2

BITMAP CONVERSION FROM ROWIDS 7.3.2

BITMAP CONSTRUCTION 7.3.2

BITMAP COMPACTION 7.3.2


Bitmap Index Operation Introduced in 7.3 Options are

BITMAP INDEX (SINGLE VALUE) Builds a single bitmap for a given value

BITMAP INDEX (RANGE SCAN) Builds a bitmap containing each value in the range

BITMAP INDEX (FULL SCAN) Builds a bitmap containing each value in the index

BITMAP INDEX (FAST FULL SCAN) Oracle 9.0.1 and above Equivalent to INDEX (FAST FULL SCAN)

12


Bitmap Conversion Operation Introduced in Oracle 7.3 Options are

BITMAP CONVERSION (TO ROWIDS) Converts a bitmap into a set of ROWIDs

BITMAP CONVERSION (COUNT) Returns the number of set bits in a bitmap Used to implement COUNT() aggregates

BITMAP CONVERSION (FROM ROWIDS) Converts a set of ROWIDs into a bitmap

13


Bitmap And Operation Introduced in Oracle 7.3 Performs logical AND operation between two bitmaps

CREATE TABLE t1 (c1 NUMBER, c2 NUMBER);CREATE BITMAP INDEX i1 ON t1 (c1);CREATE BITMAP INDEX i2 ON t1 (c2);

0 SELECT STATEMENT Optimizer=CHOOSE1 0 BITMAP CONVERSION (TO ROWIDS)2 1 BITMAP AND3 2 BITMAP INDEX (SINGLE VALUE) OF 'I1‘4 2 BITMAP INDEX (SINGLE VALUE) OF 'I2‘

SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2FROM t1WHERE c1 = 0 AND c2 = 0;

14


Bitmap Or Operation Introduced in Oracle 7.3 Performs logical OR operation between two bitmaps


0 SELECT STATEMENT Optimizer=CHOOSE1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1‘2 1 BITMAP CONVERSION (TO ROWIDS)3 2 BITMAP OR4 3 BITMAP INDEX (SINGLE VALUE) OF 'I1‘5 3 BITMAP INDEX (SINGLE VALUE) OF 'I2'

SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2FROM t1WHERE c1 = 0 OR c2 = 0;

15


Bitmap Minus Operation Introduced in Oracle 7.3 Performs logical MINUS operation between two bitmaps


0 SELECT STATEMENT Optimizer=CHOOSE1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1‘2 1 BITMAP CONVERSION (TO ROWIDS)3 2 BITMAP MINUS4 3 BITMAP MINUS5 4 BITMAP INDEX (SINGLE VALUE) OF 'I1‘6 4 BITMAP INDEX (SINGLE VALUE) OF 'I2‘7 3 BITMAP INDEX (SINGLE VALUE) OF 'I2'

SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2FROM t1WHERE c1 = 0 AND NOT c2 = 0;

16


Bitmap Merge Operation Introduced in Oracle 7.3 Merges two or more bitmaps together


0 SELECT STATEMENT Optimizer=CHOOSE1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1' 2 1 BITMAP CONVERSION (TO ROWIDS)3 2 BITMAP AND4 3 BITMAP INDEX (SINGLE VALUE) OF 'I2‘5 3 BITMAP MERGE6 5 BITMAP INDEX (RANGE SCAN) OF 'I1'

SELECT /*+ INDEX_COMBINE (t1 i1 i2) */ c1,c2FROM t1WHERE c1 > 0 AND c2 = 0;

17


Bitmap Construction / Compaction Introduced in Oracle 7.3 Used by index creation/rebuild operations Appear in EXPLAIN PLAN Do not appear in AUTOTRACE or V$SQL_PLAN

CREATE TABLE t1 (c1 NUMBER);

0 CREATE INDEX STATEMENT Optimizer=CHOOSE1 0 INDEX BUILD (NON UNIQUE) OF 'I1‘2 1 BITMAP COMPACTION3 2 SORT (CREATE INDEX)4 3 BITMAP CONSTRUCTION5 4 TABLE ACCESS (FULL) OF 'T1'

EXPLAIN PLAN FOR CREATE BITMAP INDEX i1 ON t1 (c01)

18


Bitmap Key Iteration Introduced in Oracle 7.3 Used to implement star transformations Star transformations join three or more tables together

-- Create fact table CREATE TABLE fact (factkey NUMBER,dim1key NUMBER,dim2key NUMBER);

-- Create bitmap indexes on fact columnsCREATE BITMAP INDEX index1 ON fact (dim1key);CREATE BITMAP INDEX index2 ON fact (dim2key);

-- Set the number of rows BEGIN

DBMS_STATS.SET_TABLE_STATS(USER,’FACT’,numrows=>100000);END;

-- Create dimension tables CREATE TABLE dim1 (dim1key NUMBER,dim1desc NUMBER);CREATE TABLE dim2 (dim2key NUMBER,dim2desc NUMBER);

19


Bitmap Key Iteration Star transformations require the following parameter

SELECT /*+ STAR_TRANSFORMATION */ fact.factkey,dim1.dim1key,dim2.dim2key

FROM fact, dim1, dim2WHERE dim1.dim1key = fact.dim1keyAND dim2.dim2key = fact.dim2keyAND dim1.dim1desc = 100AND dim2.dim2desc = 200;

ALTER SESSION SET star_transformation_enabled = TRUE;

The statement

20


Bitmap Key Iteration In Oracle 9.0.1 and above, the following plan is generated

0 SELECT STATEMENT Optimizer=CHOOSE1 0 HASH JOIN2 1 MERGE JOIN (CARTESIAN)3 2 TABLE ACCESS (FULL) OF ‘DIM1' 4 2 BUFFER (SORT)5 4 TABLE ACCESS (FULL) OF ‘DIM2' 6 1 TABLE ACCESS (BY INDEX ROWID) OF ‘FACT‘7 6 BITMAP CONVERSION (TO ROWIDS)8 7 BITMAP AND9 8 BITMAP MERGE10 9 BITMAP KEY ITERATION11 10 TABLE ACCESS (FULL) OF ‘DIM1‘12 10 BITMAP INDEX (RANGE SCAN) OF 'INDEX1‘13 8 BITMAP MERGE14 13 BITMAP KEY ITERATION15 14 TABLE ACCESS (FULL) OF ‘DIM2‘16 14 BITMAP INDEX (RANGE SCAN) OF 'INDEX2'

21


B*Tree Bitmap Plans In Oracle 7.3 and above it is possible to convert B*tree indexes

into bitmaps Enabled using _B_TREE_BITMAP_PLANS parameter Default value FALSE (8.1.7 and below), TRUE (9.0.1 and above)

CREATE TABLE t1 (c1 NUMBER, c2 NUMBER);

BEGINFOR f IN 0..9999 LOOP

INSERT INTO t1 VALUES (MOD (f,100), MOD (f,200));END LOOP;

END;

COMMIT;

CREATE INDEX i1 ON t1 (c1); -- Not bitmap indexCREATE INDEX i2 ON t1 (c2); -- Not bitmap index

ANALYZE TABLE t1 COMPUTE STATISTICS;

For example (8192 byte block size)

22


B*Tree Bitmap Plans In Oracle 9.2 the statement

SELECT c1, c2 FROM t1 WHERE c1 = 0 AND c2 = 0;

generates the plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5)1 0 BITMAP CONVERSION (TO ROWIDS)2 1 BITMAP AND3 2 BITMAP CONVERSION (FROM ROWIDS)4 3 INDEX (RANGE SCAN) OF 'I2' (NON-UNIQUE) (Cost=1)5 2 BITMAP CONVERSION (FROM ROWIDS)6 5 INDEX (RANGE SCAN) OF 'I1' (NON-UNIQUE) (Cost=1)

23


Internal Structure

24


Leaf Block Format Each value in the index is represented by one or more bitmaps Each bitmap represents a range of ROWIDs Each leaf row entry typically contains four columns

Column Description

1 Column Value

2 Start ROWID

3 End ROWID

4 Bitmap

A multi-column index will have additional key columns Branch block format and characteristics are identical to B*Tree

indexes

25


Key

Start ROWID

End ROWID

Bitmap

Bitmaps and Leaf Blocks For example, consider a bitmap index on column BEDROOMS

Block 212Block 211

PROPERTY_CODE

BEDROOMS

RECEPTIONS

GARAGES

2 4 3 3

1 2 3 4

1 3 2 2

0 2 1 1

2

211/0

212/3

10000010

3

211/0

212/3

00110101

4

211/0

212/3

01001000

4 3 2 3

5 6 7 8

3 2 1 2

2 1 1 2

1 2 3 4

1 3 2 2

0 2 1 1

5 6 7 8

3 2 1 2

2 1 1 2

26


Bitmap Block Dump Partial block dump for the previous slide

row#0[8013] flag: -----, lock: 0col 0; len 2; (2): c1 03col 1; len 6; (6): 01 00 01 82 00 00col 2; len 6; (6): 01 00 01 83 00 07col 3; len 3; (3): 00 c2 44

row#1[7988] flag: -----, lock: 0col 0; len 2; (2): c1 04col 1; len 6; (6): 01 00 01 82 00 00col 2; len 6; (6): 01 00 01 83 00 07col 3; len 5; (5): c8 0c f8 56 0a

row#2[7965] flag: -----, lock: 0col 0; len 2; (2): c1 05col 1; len 6; (6): 01 00 01 82 00 00col 2; len 6; (6): 01 00 01 83 00 07col 3; len 3; (3): 01 c0 44

Key

Start ROWID

End ROWID

Bitmap

27


B*Tree Block Dump

row#0[8024] flag: -----, lock: 0col 0; len 2; (2): c1 03col 1; len 6; (6): 01 00 01 82 00 00




Key

ROWID





28


Bitmap Pieces Every bitmap piece has a start ROWID and an end ROWID

Start ROWID is rounded to the nearest byte boundary below End ROWID is rounded to the nearest byte boundary above

Each indexed column value may have one or more bitmap pieces

A bitmap piece covers a contiguous set of rows in one or more extents may cross extent boundaries may split within a block

29


Bitmap Pieces For example the following are all valid bitmap pieces

Start 211/0 End 533/15

Start 532/0 End 533/15

End 533/7Start 211/8

Block 211 Block 532 Block 533

Start 532/8 End 532/15

Start 211/0 End 533/15Start 533/0End 532/15

Start 211/0 End 533/15Start 532/8End 532/7

Extent 1 Extent 2

Start 211/0 End 211/15

30


Compression Algorithm Bitmaps consists of zeros and ones Zeros are compressed; ones are not compressed Bitmaps can be subdivided into groups of bytes First byte in each group determines length of group

First Byte Description

< 192 Single-byte group

>= 192 Multi-byte group

31


Single-Byte Groups Byte represents the number of zero bits followed by a one bit Maximum of 191 zero bits

Byte Bitmap

00 10000000

01 01000000

02 00100000

03 00010000

08 00000000 10000000

0F 00000000 00000001

10 00000000 00000000 10000000

11 00000000 00000000 01000000

17 00000000 00000000 00000001

18 00000000 00000000 00000000 10000000

19 00000000 00000000 00000000 01000000

Range of byte values is 0x00 to 0xBF

32


Multi-Byte Groups Multi-byte groups allow more than 192 bits to be skipped First byte is a control byte

Next three bits indicate number of zero bytes to skip If all three bits are set then number overflows to second byte If top bit of second byte is set then number of zero bytes

overflows to third byte

First two bits indicate this is a control byte (always 11)

Last three bits indicate number of bytes following control block (minimum 1, maximum 8)

1 1

33


Multi-Byte Groups Examples

Code Number ofZero Bytes

Number ofZero BitsHex Binary

C8 11001000 0 0

D0 11010000 1 8

D8 11011000 2 16

E0 11100000 3 24

E8 11101000 4 32

F0 11110000 5 40

F8 00 11111000 00000000 6 48

F8 01 11111000 00000001 7 56

F8 02 11111000 00000010 8 64

F8 7F 11111000 01111111 133 1064

F8 80 01 11111000 10000000 00000001 134 1072

F8 81 01 11111000 10000001 00000001 135 1080

34


Multi-Byte Groups Last three bits indicate number of bytes following control

block (minimum 1, maximum 8)

Code Number of

bytes

Example

Hex Binary

C8 11001000 1 C8 FF

C9 11001001 2 C9 FF FF

CA 11001010 3 CA FF FF FF

CB 11001011 4 CB FF FF FF FF

CC 11001100 5 CC FF FF FF FF FF

CD 11001101 6 CD FF FF FF FF FF FF

CE 11001110 7 CE FF FF FF FF FF FF FF

CF 11001111 8 CF FF FF FF FF FF FF FF FF

35


Håkan Factor For each table describes maximum number of rows that each

block can theoretically hold Derived from column definition Affected by

Number of columns Column datatypes and lengths NOT NULL constraints

Stored in lower 11 (at least) bits of SYS.TAB$.SPARE1 Minimum value is 11 bytes per row to allow row to be migrated

Block Size Maximum Rows per Block

2048 178

4096 364

8192 736

16384 1481

36


Håkan Factor Håkan Factor can be adjusted using

ALTER TABLE table_name MINIMIZE RECORDS_PER_BLOCK;

This command Scans entire table Counts number of rows in each block Sets Håkan Factor in SPARE1 to maximum row count Sets bit 0x8000 in SPARE1 to indicate value has been set

Subsequently modified blocks will be limited to the new Håkan Factor

Command is reversed using

ALTER TABLE table_name NOMINIMIZE RECORDS_PER_BLOCK;

37


Håkan Factor Hakan Factor is used when compressing bitmaps Each bitmap represents an array

Blocks

Maximum rows per block

Minimising records per block reduces size of this array

Blocks

Maximum rows per block Reduces memory required to access/manipulate bitmap May reduce disk space required to hold bitmap

38


Nulls B*Tree indexes do not include NULL values Bitmap indexes do include a leaf row for NULL values For example, if I1 is a bitmap index, the statement

SELECT COUNT(*) FROM t1WHERE c1 IS NULL;

generates the plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5)1 0 SORT (AGGREGATE)2 1 BITMAP CONVERSION (COUNT)3 2 BITMAP INDEX (SINGLE VALUE) OF ‘I1'

If I1 is a B*Tree index the same statement generates the plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=5)1 0 SORT (AGGREGATE)2 1 TABLE ACCESS (FULL) OF ‘T1’

39


Distinct Keys This example shows how the number of distinct keys affects

number of leaf blocks for 100000 row table 8192 byte block size

Distinct Keys B*Tree Bitmap

1 237 3

2 237 5

5 237 13

10 237 25

100 237 50

1000 237 48

10000 237 87

50000 237 210

100000 237 363

0

50

100

150

200

250

300

350

400

Distinct Keys

Le

af

Blo

ck

s

B*Tree Bitmap

40


Clustering Size of bitmap indexes is affected by the clustering of the data For example 100000 row table Column1 and Column2 contain 100 distinct values

Column1 (Distributed)

Column2 (Clustered)

Column1 (Distributed)

Column2(Clustered)

Height 2 2

Blocks 24 8

Leaf Rows 100 100

Leaf Blocks 20 3

Branch Rows 19 2

Branch Blocks 1 1

41


Bitmap Index DML

42


Inserts In Oracle 9.2 and below, insertion is very inefficient When a row is inserted

if leaf row already exists for ROWID then bitmap is updated otherwise a new leaf row is inserted for the eight bits

around the new row

In Oracle 10g, insertion is more efficient rows are inserted into existing leaf rows where possible if necessary start ROWID or end ROWID is adjusted

43


Inserts Insertion behaviour in Oracle 9.2 and below

Bitmap Index Leaf Rows

Block 573 Block 574

Table Rows

2

573/0

574/7

Key

Start

End

Block 575

2

574/8

574/15

Key

Start

End

2

575/0

575/7

Key

Start

End

2

575/8

575/15

Key

Start

End

Key = 2

Key <> 2

44


Inserts Insertion behaviour in Oracle 10g

Bitmap Index Leaf Rows

Block 573 Block 574

Table Rows

2

573/0

574/7

Key

Start

End

Block 575

574/15575/7575/15

Key = 2

Key <> 2

45


Updates As with B*Tree indexes updates consist of a delete followed

by an insert delete old value from bitmap piece add new value from bitmap piece

At least two bitmap pieces are affected by every update

Also applies to bitmap indexes containing NULL values

When bitmaps are updated on a block Must have sufficient space on block for old and new rows Otherwise block is split Can lead to long branch block rows

46


Locking When a bitmap index is updated, a row lock is taken for the

index leaf entry

The index leaf entry contains a bitmap which may cover many rows across a number of blocks

No other transaction can update an indexed column in any row covered by that bitmap piece until the original transaction commits or rolls back

47


LockingBitmap Index Leaf Rows

2

10499 100 107

43 3 2

515 20 10

9792 94 98

34 2 3

1525 10 20

8986 88 90

43 3 2

1510 20 5

8077 78 83

43 3 2

1025 5 5

Block 211 Block 212 Block 213 Block 214

c1

c2

c3

333 4 4 44

Table Rows

2

211/0

214/3

Key

Start

End

Lock 0

3

211/0

212/3

Key

Start

End

Lock 0

3

211/0

212/3

Key

Start

End

Lock 1

3

213/0

214/3

Key

Start

End

Lock 0

4

211/0

214/3

Key

Start

End

Lock 0

4

211/0

214/3

Key

Start

End

Lock 1

4

20

88

CREATE BITMAP INDEX i1 ON t1 (c2);

UpdatedUPDATE t1SET c2 = 4WHERE c1 = 88;

Locked

48


Leaf Block Splits When bitmaps indexes are updated

Old row is retained until transaction is committed New row is written to free space in block If no free space in existing block, new block is used Leaf rows stored in ascending order Key, start and end ROWIDs are unchanged therefore leaf

row ordered by bitmap

If last bitmap in block is updated then block is split Branch blocks contain unique leading edge for columns If change is at end of bitmap, entire bitmap may be copied

up into branch block

49


Leaf Block Splits Example of leaf block split Oracle 9.2 – 8192 byte block size 8 distinct values – approximately 3000 rows each

1 2START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

3 4START

END

001000000100000010000001100000

000010000001100000010000001000

STARTEND

5 6START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

7 8START

END

001000000100000010000001100000

000100000010000001100000010000

STARTEND

3 51 7BranchBlock

LeafBlocks

Initial state. Branch rows initial contain index key values only

50


Leaf Block Splits

1 2START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

2START

END

100000010000001000000100000010

3 4START

END

001000000100000010000001100000

000010000001100000010000001000

STARTEND

4START

END

100000010000001000000100000010

5 6START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

7 8START

END

001000000100000010000001100000

000100000010000001100000010000

STARTEND

UPDATE t1 SET c2 = 2 /* was 4 */WHERE c1 = 23988;

2 3STARTEND

100000010000001000000100000010

41STARTEND

010000001000000100000010000001

75

Updated

Deleted

BranchBlock

LeafBlocks

Deleted row is retained until end of transaction. Leaf block splits between updated and deleted rows. Branch row must contain bitmap

51


Leaf Block Splits

1 2START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

2START

END

100000010000001000000100000010

3 4START

END

001000000100000010000001100000

000010000001100000010000001000

STARTEND

4START

END

100000010000001000000100000010

5 6START

END

100000010000001000000100000010

010000001000000100000010000001

STARTEND

6START

END

100000010000001000000100000010

7 8START

END

001000000100000010000001100000

000100000010000001100000010000

STARTEND

8START

END

000010000001100000010000001000

51

2 3START

END

100000010000001000000100000010

41STARTEND

010000001000000100000010000001

6 7START

END

100000010000001000000100000010

85STARTEND

010000001000000100000010000001

UPDATE t1 SET c2 = 6 /* was 8 */WHERE c1 = 23992;

Updated

Deleted

Insufficient space for new branch rows in branch blockBranch block splits. New root block created. Index height increases

52


Conclusions Columns with relatively high cardinality may be suitable for

bitmap indexes

Clustering of data significantly affects bitmap index size

DML is very inefficient in Oracle 9i and below; in Oracle 10g it is much more efficient

Be aware of implications of locking when indexes are updated by multiple sessions

In Oracle 10g bitmap indexes are viable for volatile tables if all updates are made by one session

53


References Jonathan Lewis

Understanding Bitmap Indexes (http://www.dbazine.com) Optimising Oracle – Performance by Design 2001-2003

Steve Adams Miracle Master Class 2003

Julian Dyke (http://www.juliandyke.com)

54


Thank you for your interest

For more information and to provide feedback

please contact me

My e-mail address is:[email protected]

My website address is:

www.juliandyke.com

1 juliandyke.com Bitmap Index Internals Julian Dyke Independent Consultant Web Version © 2005...

Documents

Transcript of 1 juliandyke.com Bitmap Index Internals Julian Dyke Independent Consultant Web Version © 2005...