Javier Villegas

My feedback

  1. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Javier Villegas shared this idea  · 
  2. 1 vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Javier Villegas supported this idea  · 
  3. 183 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    under review  ·  35 comments  ·  SQL Server » Setup + Deployment  ·  Flag idea as inappropriate…  ·  Admin →
    Javier Villegas commented  · 

    This is really important. for my environment. Please put it back

    Javier Villegas supported this idea  · 
  4. 13 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SQL Managed Instance  ·  Flag idea as inappropriate…  ·  Admin →
    Javier Villegas shared this idea  · 
  5. 31 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    15 comments  ·  SQL Server » Bugs  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 48

    <=-=Jul 9 2014 11:04PM=-=>

    This is happening to us, at least 3 times a week, on different tables in the database. The drop statistics on primary works, but the processes that are meant to run on the secondary via, linked servers are failing! A real pain!

    <=-=Apr 2 2015 1:38AM=-=>

    >A real pain!
    +1

    <=-=May 4 2015 3:39AM=-=>

    Microsoft folks – Can we please have some kind of explanation on why this happens for dynamic stats and on the asynchronous node only? It has been a real pain for us to manually drop the statistic on the primary node to clean up the corrupt statistic on the asynchronous secondary node.

    <=-=May 19 2015 11:48PM=-=>

    Clearing the userstore_dbmetadata related pools on ASYNC commit resolves the issue.
    DBCC FREESYSTEMCACHE (‘dbname’)

    Or create a stored procedure to check if the instance is an ASYNC commit, then clear the cache using an…

    Javier Villegas commented  · 

    This is still happening to me once in a while. it is quite annoying since we rely on the RO replica and the day we have this issue most of the processes fails because of this

Feedback and Knowledge Base