Internal Architecture of MDF file

--I just created a new datbase. Added one row to the table and an index.
--Looking at the mdf file using a hex editor surprised me.
create database mydb1
go
use mydb1
go
create table table1 (a char(10), b char(10))
go
insert into table1 values ('firstTest','23571113') --primes 2-13 if you care.
--Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
--Search for string 23571113. You will find one (1). Only one.
--Start sql
use mydb1
go
create index idx1 on table1(b)
--Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
--Search for string 23571113. You will find THREE (3). Why?
--Serious replies only please.
/Bob
Bob,
You don't need a hex editor; you use use DBCC PAGE to view the page
structures without going to all of this trouble. Syntax here:
http://www.sql-server-performance.co...ented_dbcc.asp
If you're really interested in this stuff, you should get a copy of Kalen
Delaney's _Inside SQL Server 2000_, which describes the structures in great
detail.
"Bob" <utefan001@.gmail.com> wrote in message
news:40692455.0409281803.4ce67381@.posting.google.c om...
> --I just created a new datbase. Added one row to the table and an index.
> --Looking at the mdf file using a hex editor surprised me.
> create database mydb1
> go
> use mydb1
> go
> create table table1 (a char(10), b char(10))
> go
> insert into table1 values ('firstTest','23571113') --primes 2-13 if you
care.
> --Stop here..Shut down sql and view the mdf file with a hex editor
(hackman)
> --Search for string 23571113. You will find one (1). Only one.
> --Start sql
> use mydb1
> go
> create index idx1 on table1(b)
> --Stop here..Shut down sql and view the mdf file with a hex editor
(hackman)
> --Search for string 23571113. You will find THREE (3). Why?
> --Serious replies only please.
> /Bob
|||See
http://www.nigelrivett.net/PageStructure.html
"Bob" wrote:

> --I just created a new datbase. Added one row to the table and an index.
> --Looking at the mdf file using a hex editor surprised me.
> create database mydb1
> go
> use mydb1
> go
> create table table1 (a char(10), b char(10))
> go
> insert into table1 values ('firstTest','23571113') --primes 2-13 if you care.
> --Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
> --Search for string 23571113. You will find one (1). Only one.
> --Start sql
> use mydb1
> go
> create index idx1 on table1(b)
> --Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
> --Search for string 23571113. You will find THREE (3). Why?
> --Serious replies only please.
> /Bob
>
|||Maybe its got to do with additional pointers in the index ?
Dylan
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:#kbGikcpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> Bob,
> You don't need a hex editor; you use use DBCC PAGE to view the page
> structures without going to all of this trouble. Syntax here:
>
http://www.sql-server-performance.co...ented_dbcc.asp
> If you're really interested in this stuff, you should get a copy of Kalen
> Delaney's _Inside SQL Server 2000_, which describes the structures in
great
> detail.
>
> "Bob" <utefan001@.gmail.com> wrote in message
> news:40692455.0409281803.4ce67381@.posting.google.c om...
> care.
> (hackman)
> (hackman)
>

Internal Architecture of MDF file

--I just created a new datbase. Added one row to the table and an index.
--Looking at the mdf file using a hex editor surprised me.
create database mydb1
go
use mydb1
go
create table table1 (a char(10), b char(10))
go
insert into table1 values ('firstTest','23571113') --primes 2-13 if you care.
--Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
--Search for string 23571113. You will find one (1). Only one.
--Start sql
use mydb1
go
create index idx1 on table1(b)
--Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
--Search for string 23571113. You will find THREE (3). Why'
--Serious replies only please.
/BobBob,
You don't need a hex editor; you use use DBCC PAGE to view the page
structures without going to all of this trouble. Syntax here:
http://www.sql-server-performance.com/ac_sql_server_2000_undocumented_dbcc.asp
If you're really interested in this stuff, you should get a copy of Kalen
Delaney's _Inside SQL Server 2000_, which describes the structures in great
detail.
"Bob" <utefan001@.gmail.com> wrote in message
news:40692455.0409281803.4ce67381@.posting.google.com...
> --I just created a new datbase. Added one row to the table and an index.
> --Looking at the mdf file using a hex editor surprised me.
> create database mydb1
> go
> use mydb1
> go
> create table table1 (a char(10), b char(10))
> go
> insert into table1 values ('firstTest','23571113') --primes 2-13 if you
care.
> --Stop here..Shut down sql and view the mdf file with a hex editor
(hackman)
> --Search for string 23571113. You will find one (1). Only one.
> --Start sql
> use mydb1
> go
> create index idx1 on table1(b)
> --Stop here..Shut down sql and view the mdf file with a hex editor
(hackman)
> --Search for string 23571113. You will find THREE (3). Why'
> --Serious replies only please.
> /Bob|||See
http://www.nigelrivett.net/PageStructure.html
"Bob" wrote:
> --I just created a new datbase. Added one row to the table and an index.
> --Looking at the mdf file using a hex editor surprised me.
> create database mydb1
> go
> use mydb1
> go
> create table table1 (a char(10), b char(10))
> go
> insert into table1 values ('firstTest','23571113') --primes 2-13 if you care.
> --Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
> --Search for string 23571113. You will find one (1). Only one.
> --Start sql
> use mydb1
> go
> create index idx1 on table1(b)
> --Stop here..Shut down sql and view the mdf file with a hex editor (hackman)
> --Search for string 23571113. You will find THREE (3). Why'
> --Serious replies only please.
> /Bob
>|||Maybe its got to do with additional pointers in the index ?
Dylan
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:#kbGikcpEHA.1668@.TK2MSFTNGP14.phx.gbl...
> Bob,
> You don't need a hex editor; you use use DBCC PAGE to view the page
> structures without going to all of this trouble. Syntax here:
>
http://www.sql-server-performance.com/ac_sql_server_2000_undocumented_dbcc.asp
> If you're really interested in this stuff, you should get a copy of Kalen
> Delaney's _Inside SQL Server 2000_, which describes the structures in
great
> detail.
>
> "Bob" <utefan001@.gmail.com> wrote in message
> news:40692455.0409281803.4ce67381@.posting.google.com...
> > --I just created a new datbase. Added one row to the table and an index.
> > --Looking at the mdf file using a hex editor surprised me.
> > create database mydb1
> > go
> > use mydb1
> > go
> > create table table1 (a char(10), b char(10))
> > go
> > insert into table1 values ('firstTest','23571113') --primes 2-13 if you
> care.
> > --Stop here..Shut down sql and view the mdf file with a hex editor
> (hackman)
> > --Search for string 23571113. You will find one (1). Only one.
> > --Start sql
> >
> > use mydb1
> > go
> > create index idx1 on table1(b)
> > --Stop here..Shut down sql and view the mdf file with a hex editor
> (hackman)
> > --Search for string 23571113. You will find THREE (3). Why'
> > --Serious replies only please.
> > /Bob
>sql

Interesting problem, Why did this happen with an index?

One of the developers here just came accross an interesting problem, I am
interested to know if there is anyone out there that can explain this to me
as to why the sql server internals are behaving this way:
Table A - > has a trigger for delete that does this: Delete FROM table B.
Table B - > has an FK to table A with On Cascade delete defined.
As is, DELETE FORM TableA works perfect, no problems.
Now, for performance reasons, a unique index is introduced on Table B that
includes the FK.
Now, DELETE FORM TableA causes an error indicating that the nesting of
triggers, stored procedures, etc, is greater than 32.
If anyone can explain why the introduction of an index in this case results
in the nesting limit being exceeded, it clearly created a never ending loop
some how, I am just unclear as to how this is happening.
Thanks,
Rick.
Rick wrote:
> One of the developers here just came accross an interesting problem,
> I am interested to know if there is anyone out there that can explain
> this to me as to why the sql server internals are behaving this way:
> Table A - > has a trigger for delete that does this: Delete FROM
> table B.
> Table B - > has an FK to table A with On Cascade delete defined.
> As is, DELETE FORM TableA works perfect, no problems.
> Now, for performance reasons, a unique index is introduced on Table B
> that includes the FK.
> Now, DELETE FORM TableA causes an error indicating that the nesting of
> triggers, stored procedures, etc, is greater than 32.
> If anyone can explain why the introduction of an index in this case
> results in the nesting limit being exceeded, it clearly created a
> never ending loop some how, I am just unclear as to how this is
> happening.
> Thanks,
> Rick.
Is this a real production issue? If so, why do have a trigger on table A
to delete related rows from table B and a cascade FK on Table B to
delete related rows in Table A. Design-wise, it seems messy and
unmanageable. Or is this just a case of a developer trying to break SQL
Server.
Can you provide more details. What rows are being deleted from the
trigger? What is the actual relationship between the tables?
David Gugick
Imceda Software
www.imceda.com

Interesting problem, Why did this happen with an index?

One of the developers here just came accross an interesting problem, I am
interested to know if there is anyone out there that can explain this to me
as to why the sql server internals are behaving this way:
Table A - > has a trigger for delete that does this: Delete FROM table B.
Table B - > has an FK to table A with On Cascade delete defined.
As is, DELETE FORM TableA works perfect, no problems.
Now, for performance reasons, a unique index is introduced on Table B that
includes the FK.
Now, DELETE FORM TableA causes an error indicating that the nesting of
triggers, stored procedures, etc, is greater than 32.
If anyone can explain why the introduction of an index in this case results
in the nesting limit being exceeded, it clearly created a never ending loop
some how, I am just unclear as to how this is happening.
Thanks,
Rick.Rick wrote:
> One of the developers here just came accross an interesting problem,
> I am interested to know if there is anyone out there that can explain
> this to me as to why the sql server internals are behaving this way:
> Table A - > has a trigger for delete that does this: Delete FROM
> table B.
> Table B - > has an FK to table A with On Cascade delete defined.
> As is, DELETE FORM TableA works perfect, no problems.
> Now, for performance reasons, a unique index is introduced on Table B
> that includes the FK.
> Now, DELETE FORM TableA causes an error indicating that the nesting of
> triggers, stored procedures, etc, is greater than 32.
> If anyone can explain why the introduction of an index in this case
> results in the nesting limit being exceeded, it clearly created a
> never ending loop some how, I am just unclear as to how this is
> happening.
> Thanks,
> Rick.
Is this a real production issue? If so, why do have a trigger on table A
to delete related rows from table B and a cascade FK on Table B to
delete related rows in Table A. Design-wise, it seems messy and
unmanageable. Or is this just a case of a developer trying to break SQL
Server.
Can you provide more details. What rows are being deleted from the
trigger? What is the actual relationship between the tables?
--
David Gugick
Imceda Software
www.imceda.com