Backup and Restore Tables

  • Comments posted to this topic are about the item Backup and Restore Tables

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • As far as I know, there isn’t any DBCC REPAIR_ALLOW_DATA_LOSS command. The REPAIR_ALLOW_DATA_LOSS is one of the possible instructions to the server of what to do in case of an error when you run the command DBCC CHECKDB. If I’m correct, then the answer that is given to the question is wrong.

    Adi

    --------------------------------------------------------------
    To know how to ask questions and increase the chances of getting asnwers:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • Very good question - makes one think, but I have to agree with Adi Cohn though, that the last potential answer is wrong. The REPAIR_ALLOW_DATA_LOSS is a parameter passed to the DBCC CHECKDB command. For reference, see BOL:

    DBCC CHECKDB

    [

    [ ( 'database_name' | database_id | 0

    [ , NOINDEX

    | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]

    ) ]

    [ WITH

    {

    [ ALL_ERRORMSGS ]

    [ , NO_INFOMSGS ]

    [ , TABLOCK ]

    [ , ESTIMATEONLY ]

    [ , { PHYSICAL_ONLY | DATA_PURITY } ]

    }

    ]

    ]

    Steve Jimmo
    Sr DBA
    “If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan

  • I think you are reading too much into the wording. There is a Repair_allow_data_loss operation as part of DBCC CHECKDB. Yes, it is a parameter, but the author appears to be asking if repairs are logged.

    I have reworded the answer.

  • The author asks this question

    Introduced in SQL Server 2005, the suspect_pages table records pages considered to be suspect. Select all statements which are true as applied to this table

    DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS removes rows from the suspect_pages database, it doesn't put them in there. And the answer for DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS doesn't say anything about it, it just has it there.

    The BOL linked from the question has this to say about it.

    DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS updates the suspect_pages table to indicate each page that it has deallocated or repaired.

    How in the world does that put records in?



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • Good question for analysis

  • mtassin

    How in the world does that put records in?

    Emphasis added.

    DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS updates the suspect_pages table to indicate each page that it has deallocated or repaired.

    An update certainly answers the questions.

    Select all statements which are true as applied to this table

    . The question is NOT asking which answers insert (add) rows to the table.

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • True with regard to what?

    Here are the answers provided. Tell me how they are true or not with regard to the above question.

    Introduced in SQL Server 2005, the suspect_pages table records pages considered to be suspect. Select all statements which are true as applied to this table

    A 823 error such as a disk error.

    A 824 error - other than bad check sum or a torn page (logical error.)

    A Torn page

    A page with a bad check sum

    During a DBCC CHECKDB operation

    During a DBCC CHECKDB, REPAIR_ALLOW_DATA_LOSS operation

    Select all statements which are true as applied to this table... IN WHAT REGARD?

    The first four write new records to suspect_pages, and the last two can andd, update or remove records.

    But you don't have anything there except a bunch of words. Because you don't have statements that can be deemed true or false.

    For all I know the reference to an 823 errors could remove records from the table from what is written above.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • Here's how to write the True/False type statements to work within the context of the question

    A 823 error such as a disk error may write records to the table.

    A 824 error - other than bad check sum or a torn page (logical error.) may write records to the table.

    A Torn page may write records to the table.

    A page with a bad check sum may write records to the table.

    During a DBCC CHECKDB operation may write new records to the table or clear old ones from it

    During a DBCC CHECKDB, REPAIR_ALLOW_DATA_LOSS operation may clear records from the table

    And I use the phrase may write records to the table. because if suspect_pages is full, you get an error message in the event log instead.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • Argument #1: "During a DBCC CHECKDB, REPAIR_ALLOW_DATA_LOSS operation" This operation adds no records to the table, so how can this statement be true with regards to "the suspect_pages table records pages considered to be suspect"? No new page can be recorded by this command. Rows may be updated as repaired, but the question didn't say "tracks the status of suspect pages".

    Argument #2: The documentation for SQL 2005 only lists 824 errors, not 823 errors. The only version mentioned in the question is SQL 2005, no fair sneaking in SQL 2008 answers.

    This was an interesting question, it's a shame it was so horribly written. The statements are all incomplete phrases so they don't really have a truth value.

  • I agree with Scott, in the SQL 2005 docu it shows nothing about 823

    http://msdn.microsoft.com/en-us/library/ms191301(SQL.90).aspx

    Poorly written question but great information!

  • Scott Coleman (8/6/2009)


    This was an interesting question, it's a shame it was so horribly written. The statements are all incomplete phrases so they don't really have a truth value.

    Thanks Scott, that was my point entirely. 🙂



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • mtassin (8/6/2009)


    Here's how to write the True/False type statements to work within the context of the question

    I agree. I was torn by DBCC CHECKDB, REPAIR_ALLOW_DATA_LOSS answer becuase it didn't seem to make a complete statement in the context of the question. But I flipped a coin and got it right.

  • None of the provided answers are statements, therefore the correct answer should be none of the above.

  • I suppose I missed something: http://msdn.microsoft.com/en-us/library/ms191301.aspx

    What you don't know won't hurt you but what you know will make you plan to know better

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply