DBCC CHECKDB on Always On databases

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
2
down vote

favorite












Do we really need to run DBCC checkdb on a database configured with Always On synchronous updates?



I believe the automatic page repair mechanism should identify the corruption and repair it automatically.










share|improve this question









New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
    – scsimon
    51 mins ago

















up vote
2
down vote

favorite












Do we really need to run DBCC checkdb on a database configured with Always On synchronous updates?



I believe the automatic page repair mechanism should identify the corruption and repair it automatically.










share|improve this question









New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
    – scsimon
    51 mins ago













up vote
2
down vote

favorite









up vote
2
down vote

favorite











Do we really need to run DBCC checkdb on a database configured with Always On synchronous updates?



I believe the automatic page repair mechanism should identify the corruption and repair it automatically.










share|improve this question









New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











Do we really need to run DBCC checkdb on a database configured with Always On synchronous updates?



I believe the automatic page repair mechanism should identify the corruption and repair it automatically.







sql-server availability-groups dbcc-checkdb






share|improve this question









New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 1 hour ago









Paul White♦

47.8k14257407




47.8k14257407






New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 1 hour ago









Sankar Raj Chellappan

111




111




New contributor




Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Sankar Raj Chellappan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
    – scsimon
    51 mins ago

















  • I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
    – scsimon
    51 mins ago
















I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
– scsimon
51 mins ago





I like Brent's Blog on this because he mentions a method one client dodges the performance burden of DBCC but still ensures they are checking both nodes. Also, you can read about this and methods from Aaron
– scsimon
51 mins ago











1 Answer
1






active

oldest

votes

















up vote
5
down vote













Yes you really need to run checkdb on ALL the secondary replicas. If you read MS document on Automatic Page repair it says




Automatic page repair cannot repair the following control page types:



File header page (page ID 0).



Page 9 (the database boot page).



Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.




So you can see not all types of repairs are fixed by automatic page repair. What if you encounter corruption not coming under error fixed by automatic repair.



If you are using availability groups on WSFC without FCI the storage would be local storage so you need to separately run checkdb and analyze storage for each replica.






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "182"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    Sankar Raj Chellappan is a new contributor. Be nice, and check out our Code of Conduct.









     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f221359%2fdbcc-checkdb-on-always-on-databases%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    5
    down vote













    Yes you really need to run checkdb on ALL the secondary replicas. If you read MS document on Automatic Page repair it says




    Automatic page repair cannot repair the following control page types:



    File header page (page ID 0).



    Page 9 (the database boot page).



    Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.




    So you can see not all types of repairs are fixed by automatic page repair. What if you encounter corruption not coming under error fixed by automatic repair.



    If you are using availability groups on WSFC without FCI the storage would be local storage so you need to separately run checkdb and analyze storage for each replica.






    share|improve this answer
























      up vote
      5
      down vote













      Yes you really need to run checkdb on ALL the secondary replicas. If you read MS document on Automatic Page repair it says




      Automatic page repair cannot repair the following control page types:



      File header page (page ID 0).



      Page 9 (the database boot page).



      Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.




      So you can see not all types of repairs are fixed by automatic page repair. What if you encounter corruption not coming under error fixed by automatic repair.



      If you are using availability groups on WSFC without FCI the storage would be local storage so you need to separately run checkdb and analyze storage for each replica.






      share|improve this answer






















        up vote
        5
        down vote










        up vote
        5
        down vote









        Yes you really need to run checkdb on ALL the secondary replicas. If you read MS document on Automatic Page repair it says




        Automatic page repair cannot repair the following control page types:



        File header page (page ID 0).



        Page 9 (the database boot page).



        Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.




        So you can see not all types of repairs are fixed by automatic page repair. What if you encounter corruption not coming under error fixed by automatic repair.



        If you are using availability groups on WSFC without FCI the storage would be local storage so you need to separately run checkdb and analyze storage for each replica.






        share|improve this answer












        Yes you really need to run checkdb on ALL the secondary replicas. If you read MS document on Automatic Page repair it says




        Automatic page repair cannot repair the following control page types:



        File header page (page ID 0).



        Page 9 (the database boot page).



        Allocation pages: Global Allocation Map (GAM) pages, Shared Global Allocation Map (SGAM) pages, and Page Free Space (PFS) pages.




        So you can see not all types of repairs are fixed by automatic page repair. What if you encounter corruption not coming under error fixed by automatic repair.



        If you are using availability groups on WSFC without FCI the storage would be local storage so you need to separately run checkdb and analyze storage for each replica.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 1 hour ago









        Shanky

        13.7k32039




        13.7k32039




















            Sankar Raj Chellappan is a new contributor. Be nice, and check out our Code of Conduct.









             

            draft saved


            draft discarded


















            Sankar Raj Chellappan is a new contributor. Be nice, and check out our Code of Conduct.












            Sankar Raj Chellappan is a new contributor. Be nice, and check out our Code of Conduct.











            Sankar Raj Chellappan is a new contributor. Be nice, and check out our Code of Conduct.













             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f221359%2fdbcc-checkdb-on-always-on-databases%23new-answer', 'question_page');

            );

            Post as a guest













































































            Comments

            Popular posts from this blog

            Long meetings (6-7 hours a day): Being “babysat” by supervisor

            Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

            Confectionery