Showing posts with label state. Show all posts
Showing posts with label state. Show all posts

Sunday, March 11, 2012

Auditing Status of a Trigger in SQL Server 2005

I need to know when a DML trigger changes state (from enabled to disabled, and disabled to enabled).

I **assume** this info is not in any of the standard SQL Server 2005 loags and find no entry relating to triggers being enabled/disabled.

Therefore I also *assume* the best way to do this is create a DDL Trigger and populate a table when a trigger status is changed.

Am I on the right track?

Has anyone done this? Code samples/links to solution?

Is there a simplier way <i'm all about simple>?

Thanks in advance.

Thats exactly the right direction, if you need a quikc sample for using DDL events, take a look at the DDL event definition in the BOL and perhpas at the slightly different samples on my website: http://sqlserver2005.de/articles/2/

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Sunday, February 19, 2012

Attempt to fetch logical page

After start SELECT DISTINCT.. FROM TABLE_NAME in Query
Analyzer server return:
Server: Msg 605, Level 21, State 1, Line 1
Attempt to fetch logical page (1:1031984) in
database 'Database_Name' belongs to object 'syscomments',
not to object 'Table_Name'.
Connection Broken
What does this mean ? What should I do to resolve this
problem ?
You have a corruption in your database. First, read below:
http://www.karaszi.com/SQLServer/inf...suspect_db.asp
Second, if you are on SQL Server 2000, check the specific recommendations for your error. Do this in
the *updated* version of Books Online. Here is the section for 605:
Error 605
Severity Level 21
Message Text
Attempt to fetch logical page %S_PGID in database '%.*ls' belongs to object '%.*ls', not to object
'%.*ls'.
Explanation
This error occurs when Microsoft SQL ServerT detects database corruption. The second object
specified in the text not to object '%.*ls' is probably corrupt. Because this error can mask the
existence of other errors, execute DBCC CHECKDB to determine the extent of the damage. If DBCC
CHECKDB does not report additional errors, the first object mentioned is not corrupt.
SQL Server detects database corruption when it traverses the pages of an object and finds a page in
the chain whose object ID does not match that of the object being accessed. There is probably a
damaged page chain, a corrupt Index Allocation Map (IAM), or an invalid entry in the sysobjects
system table for that object. A clustered table has one doubly-linked page chain for the table data
as well as one for each index level. A nonclustered index has a page chain for each level of the
index. Pages in a heap are not linked. The IAM is used to find the pages of a heap.
Although error 605 usually displays two object names, other variations can occur:
a.. If instead of an object name the error displays a number greater than 0, it means that an
attempt was made to reference an object ID that does not exist in a system table for that object.
b.. If the error reports the first object ID as 0, an unallocated page was probably encountered.
(There is no object ID equal to 0.)
c.. If the error states that a page belongs to object ALLOCATION, some of the allocation
structures used by the database might be corrupted.
Usually this error occurs after the corruption has been written to the database on disk, but it can
also occur entirely in the cache without the damage ever being written to the disk. This is known as
a transient 605 error and is not associated with data corruption. If error 605 occurs during data
access, but subsequent DBCC CHECKDB statements complete without error, the 605 error was probably
transient. Transient 605 errors can be caused by the operating system prematurely notifying SQL
Server that an I/O operation has completed; the error message is displayed even though no actual
data corruption exists.
Nontransient 605 errors are often caused by hardware or disk device driver failure.
Action
Execute DBCC CHECKTABLE on the second object specified in the error message. To determine the full
extent of the corruption, execute DBCC CHECKDB as soon as possible. Also check the error log for
other errors, which often accompany a 605 error.
If the 605 error is not transient, the problem is severe and you must run DBCC CHECKDB with one of
the repair clauses. If the error involves an index page, use the REPAIR_REBUILD clause. If the error
involves a data page, it may be necessary to use the REPAIR_ALLOW_DATA_LOSS clause. In the likely
event that you cannot allow the loss of data, you will need to restore from a known clean backup. If
the problem persists, contact your primary support provider. Have the output from DBCC CHECKDB
available for review.
Important If running DBCC CHECKDB with one of the repair clauses does not correct the index
problem, or if you are unsure what effect DBCC CHECKDB with a repair clause has on your data,
contact your primary support provider.
In addition, run hardware diagnostics and correct any problems. You might find it beneficial to
perform a completely new setup on the computer, including reformatting the disk drives and
reinstalling the operating system. This eliminates the possibility that a .dll or .exe program is
corrupted. You can also examine your operating-system error log to see if the error occurred as the
result of hardware failure.
Finally, be sure that your system does not have write caching enabled on the disk controller. If you
suspect this to be the problem, contact your hardware vendor.
Additional Information
DBCC CHECKDB offers the REPAIR_REBUILD and REPAIR_ALLOW_DATA_LOSS clauses. The REPAIR_REBUILD clause
rebuilds corrupt indexes and the REPAIR_ALLOW_DATA_LOSS clause fixes allocation problems. Sometimes,
deleting pages is the only way to fix allocation problems. Typically, these pages contain data that
was already deleted, but the pages may contain valid data. Therefore, deleting pages is a more risky
option than using DBCC CHECKDB with a repair clause. Using DBCC CHECKDB with a repair clause fixes
database corruption when a database backup is not available.
If your database is a data warehouse, you may be able to continue operating without the lost data
for some time before reloading the missing data. In these cases, use DBCC CHECKDB with the
REPAIR_ALLOW_DATA_LOSS clause to fix the damaged database.
You can prevent problems by following these guidelines:
1.. Run SQL Server only on hardware and controllers that are certified for your operating system.
2.. Perform regular backups in conjunction with DBCC CHECKDB statements. DBCC CHECKDB performs all
checks that DBCC NEWALLOC and DBCC CHECKALLOC previously did, but DBCC CHECKDB is faster. This is
the only way to be confident of the state of the database at the time of the backup.
3.. If the data is critical, back up the transaction log frequently. This makes it possible to
reduce your window of vulnerability, even in the event of a catastrophic hardware problem, to an
hour or less.
4.. In the most critical situations, use a standby server and a continually running batch job to
take transaction backups off of the primary computer and continually restore them on the standby
computer.
5.. If you have persistent data corruption problems, try to swap the computer, the controllers,
and the disk device drivers for components of a different type. This makes it easier to determine
whether the problem is specifically platform-related.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MK" <anonymous@.discussions.microsoft.com> wrote in message
news:36f201c4a54e$c3b508b0$a301280a@.phx.gbl...
> After start SELECT DISTINCT.. FROM TABLE_NAME in Query
> Analyzer server return:
> Server: Msg 605, Level 21, State 1, Line 1
> Attempt to fetch logical page (1:1031984) in
> database 'Database_Name' belongs to object 'syscomments',
> not to object 'Table_Name'.
> Connection Broken
> What does this mean ? What should I do to resolve this
> problem ?
>
begin 666 important.gif
M1TE&.#EA# `+`(#_`,P``,# P"'Y! $```$`+ `````,``L`0 (7C(\9`&H,
3X8F43>E>2]CRZFF1$V9E4 ``.P``
`
end

Attempt to fetch logical page

After start SELECT DISTINCT.. FROM TABLE_NAME in Query
Analyzer server return:
Server: Msg 605, Level 21, State 1, Line 1
Attempt to fetch logical page (1:1031984) in
database 'Database_Name' belongs to object 'syscomments',
not to object 'Table_Name'.
Connection Broken
What does this mean ? What should I do to resolve this
problem ?You have a corruption in your database. First, read below:
http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
Second, if you are on SQL Server 2000, check the specific recommendations for your error. Do this in
the *updated* version of Books Online. Here is the section for 605:
Error 605
Severity Level 21
Message Text
Attempt to fetch logical page %S_PGID in database '%.*ls' belongs to object '%.*ls', not to object
'%.*ls'.
Explanation
This error occurs when Microsoft® SQL ServerT detects database corruption. The second object
specified in the text not to object '%.*ls' is probably corrupt. Because this error can mask the
existence of other errors, execute DBCC CHECKDB to determine the extent of the damage. If DBCC
CHECKDB does not report additional errors, the first object mentioned is not corrupt.
SQL Server detects database corruption when it traverses the pages of an object and finds a page in
the chain whose object ID does not match that of the object being accessed. There is probably a
damaged page chain, a corrupt Index Allocation Map (IAM), or an invalid entry in the sysobjects
system table for that object. A clustered table has one doubly-linked page chain for the table data
as well as one for each index level. A nonclustered index has a page chain for each level of the
index. Pages in a heap are not linked. The IAM is used to find the pages of a heap.
Although error 605 usually displays two object names, other variations can occur:
a.. If instead of an object name the error displays a number greater than 0, it means that an
attempt was made to reference an object ID that does not exist in a system table for that object.
b.. If the error reports the first object ID as 0, an unallocated page was probably encountered.
(There is no object ID equal to 0.)
c.. If the error states that a page belongs to object ALLOCATION, some of the allocation
structures used by the database might be corrupted.
Usually this error occurs after the corruption has been written to the database on disk, but it can
also occur entirely in the cache without the damage ever being written to the disk. This is known as
a transient 605 error and is not associated with data corruption. If error 605 occurs during data
access, but subsequent DBCC CHECKDB statements complete without error, the 605 error was probably
transient. Transient 605 errors can be caused by the operating system prematurely notifying SQL
Server that an I/O operation has completed; the error message is displayed even though no actual
data corruption exists.
Nontransient 605 errors are often caused by hardware or disk device driver failure.
Action
Execute DBCC CHECKTABLE on the second object specified in the error message. To determine the full
extent of the corruption, execute DBCC CHECKDB as soon as possible. Also check the error log for
other errors, which often accompany a 605 error.
If the 605 error is not transient, the problem is severe and you must run DBCC CHECKDB with one of
the repair clauses. If the error involves an index page, use the REPAIR_REBUILD clause. If the error
involves a data page, it may be necessary to use the REPAIR_ALLOW_DATA_LOSS clause. In the likely
event that you cannot allow the loss of data, you will need to restore from a known clean backup. If
the problem persists, contact your primary support provider. Have the output from DBCC CHECKDB
available for review.
Important If running DBCC CHECKDB with one of the repair clauses does not correct the index
problem, or if you are unsure what effect DBCC CHECKDB with a repair clause has on your data,
contact your primary support provider.
In addition, run hardware diagnostics and correct any problems. You might find it beneficial to
perform a completely new setup on the computer, including reformatting the disk drives and
reinstalling the operating system. This eliminates the possibility that a .dll or .exe program is
corrupted. You can also examine your operating-system error log to see if the error occurred as the
result of hardware failure.
Finally, be sure that your system does not have write caching enabled on the disk controller. If you
suspect this to be the problem, contact your hardware vendor.
Additional Information
DBCC CHECKDB offers the REPAIR_REBUILD and REPAIR_ALLOW_DATA_LOSS clauses. The REPAIR_REBUILD clause
rebuilds corrupt indexes and the REPAIR_ALLOW_DATA_LOSS clause fixes allocation problems. Sometimes,
deleting pages is the only way to fix allocation problems. Typically, these pages contain data that
was already deleted, but the pages may contain valid data. Therefore, deleting pages is a more risky
option than using DBCC CHECKDB with a repair clause. Using DBCC CHECKDB with a repair clause fixes
database corruption when a database backup is not available.
If your database is a data warehouse, you may be able to continue operating without the lost data
for some time before reloading the missing data. In these cases, use DBCC CHECKDB with the
REPAIR_ALLOW_DATA_LOSS clause to fix the damaged database.
You can prevent problems by following these guidelines:
1.. Run SQL Server only on hardware and controllers that are certified for your operating system.
2.. Perform regular backups in conjunction with DBCC CHECKDB statements. DBCC CHECKDB performs all
checks that DBCC NEWALLOC and DBCC CHECKALLOC previously did, but DBCC CHECKDB is faster. This is
the only way to be confident of the state of the database at the time of the backup.
3.. If the data is critical, back up the transaction log frequently. This makes it possible to
reduce your window of vulnerability, even in the event of a catastrophic hardware problem, to an
hour or less.
4.. In the most critical situations, use a standby server and a continually running batch job to
take transaction backups off of the primary computer and continually restore them on the standby
computer.
5.. If you have persistent data corruption problems, try to swap the computer, the controllers,
and the disk device drivers for components of a different type. This makes it easier to determine
whether the problem is specifically platform-related.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MK" <anonymous@.discussions.microsoft.com> wrote in message
news:36f201c4a54e$c3b508b0$a301280a@.phx.gbl...
> After start SELECT DISTINCT.. FROM TABLE_NAME in Query
> Analyzer server return:
> Server: Msg 605, Level 21, State 1, Line 1
> Attempt to fetch logical page (1:1031984) in
> database 'Database_Name' belongs to object 'syscomments',
> not to object 'Table_Name'.
> Connection Broken
> What does this mean ? What should I do to resolve this
> problem ?
>
begin 666 important.gif
M1TE&.#EA# `+`(#_`,P``,# P"'Y! $```$`+ `````,``L`0 (7C(\9`&H,
3X8F43>E>2]CRZFF1$V9E4 ``.P``
`
end

Thursday, February 16, 2012

Attaching MDF without LDF

Hi Guys

I'm recovering from a hard disk crash, trying to reattach recovered
files.

The MDF file seems fine, but I get:

"Server: Msg 9004, Level 23, State 1, Line 1
An error occurred while processing the log for database
'NetCoverAdmin'."

when I try to include the LDF file. My command was:

EXEC sp_attach_db @.dbname = N'NetCoverAdmin',
@.filename1 = N'c:\Program Files\Microsoft SQL
Server\MSSQL\Data\NetcoverAdmin_Data.MDF',
@.filename2 = N'c:\Program Files\Microsoft SQL
Server\MSSQL\Data\NetcoverAdmin_Log.LDF'

Is there any way I can restore the database without the LDF file?

My backups where on another disk that mysteriously failed at the same
time, so I have to work what I got...

Any help appreciated!!

Thanks(Taqyon@.gmail.com) writes:
> Is there any way I can restore the database without the LDF file?

Maybe.

If there were no uncommitted transactions in the database at the time of
the crash, all data pages had been flushed to disk etc, the odds are
good.

But if there uncommitted transactions, or pages that had been written
to the log, but not to the data file, you will get a database that is
in poor shape. DBCC may report corruption. It may also come out clean,
but you may still have corruption on application level

If there is any value of that data to you, I stronly recommend you to
open a case with Microsoft, as a support engineer will guide you throuh
all the steps, and can also help you to devise procedures to check the
validity of your data.

If the cost of losing the data does not warrant a support call, but you
still want to give it a shot, I know of method that I will post here.
Simply because if it's applied without understanding, it can cause
even greater mess. Drop me a mail, if you want it.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland you Beaut!!!

Worked like a charm, data seems for the most part intact. Saved my
bacon.

Thanks a million!
Hein