Hello,
I was wondering if any body has come accross this before, and if so could
offer some advice. It's got me scratching my head.
I have a database that is backed up each night using a maintenance plan.
I have come to attempt to restore this database and it always fails with the
following error,
"An internal consistency error occured. Contact technical support for
assistance.
RESTORE DATABASE terminating abnormaly"
No matter which of the 30 odd backups from the last month I try and on any
machine, I always get the same error.
Many thanks in advance for any help offered
Yours hopefully
Chris
chris.roberts@.optima-ws.comYOu should do as the error suggests and call PSS... It is possible your
database has been corrupt for quite some time, and therefore all of your
backups are also corrupt...
"Chris Roberts" <chris.roberts@.optima-ws.com> wrote in message
news:bivr6s$39p$1@.newsg1.svr.pol.co.uk...
> Hello,
> I was wondering if any body has come accross this before, and if so could
> offer some advice. It's got me scratching my head.
> I have a database that is backed up each night using a maintenance plan.
> I have come to attempt to restore this database and it always fails with
the
> following error,
> "An internal consistency error occured. Contact technical support for
> assistance.
> RESTORE DATABASE terminating abnormaly"
> No matter which of the 30 odd backups from the last month I try and on any
> machine, I always get the same error.
> Many thanks in advance for any help offered
> Yours hopefully
> Chris
> chris.roberts@.optima-ws.com
>|||No sure if it is corrupt, one more bit off info I've found out is that if I
preform a manual backup, it restores OK, it's only when I do a backup from
the maintenance plan that I get this error. It's also the same with all the
databases, not just one
"Wayne Snyder" <wsnyder@.computeredservices.com> wrote in message
news:O3C0XfUcDHA.652@.tk2msftngp13.phx.gbl...
> YOu should do as the error suggests and call PSS... It is possible your
> database has been corrupt for quite some time, and therefore all of your
> backups are also corrupt...
> "Chris Roberts" <chris.roberts@.optima-ws.com> wrote in message
> news:bivr6s$39p$1@.newsg1.svr.pol.co.uk...
> > Hello,
> >
> > I was wondering if any body has come accross this before, and if so
could
> > offer some advice. It's got me scratching my head.
> >
> > I have a database that is backed up each night using a maintenance plan.
> >
> > I have come to attempt to restore this database and it always fails with
> the
> > following error,
> >
> > "An internal consistency error occured. Contact technical support for
> > assistance.
> > RESTORE DATABASE terminating abnormaly"
> >
> > No matter which of the 30 odd backups from the last month I try and on
any
> > machine, I always get the same error.
> >
> > Many thanks in advance for any help offered
> >
> > Yours hopefully
> >
> > Chris
> > chris.roberts@.optima-ws.com
> >
> >
>
Showing posts with label accross. Show all posts
Showing posts with label accross. Show all posts
Friday, March 30, 2012
Wednesday, March 21, 2012
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
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
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
Subscribe to:
Posts (Atom)