Post reply

Are the posted questions getting worse?

  • July 8, 2022 at 6:58 am

    #4060482

    frederico_fonseca wrote:

    Michael L John wrote:

    Is it Friday?  I feel like it should be Friday.

    No... its Sunday... special extended weekend 🙂

    Now it's Friday.  Mine started especially early too with a callout 45 minutes before my alarm!

    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • July 9, 2022 at 3:31 am

    #4060910

    Guess how my f$%^ing Saturday has started too.

    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • July 9, 2022 at 3:47 am

    #4060923

    Neil Burton wrote:

    Guess how my f$%^ing Saturday has started too.

    You mean you set your alarm on to go off on a Saturday morning 😀 😀 😀

    I won't bore you with how "lovely" the required security upgrades at my place of work have mad this Friday night. 😀 😀 😀  It's worse than doing code reviews... I'm up to about 150 WTF's in the last 4 hours or so. 😀

     

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • July 11, 2022 at 12:38 pm

    #4061618

    Dare I ask what happened Saturday that has everyone in a tizzy? As I was paying attention to family and not work or the news.

    Also, got a SQL 2017 error that's not making sense to me. Any advice appreciated here: https://www.sqlservercentral.com/forums/topic/error-could-not-find-a-login-matching-the-name-provided.

     

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • July 11, 2022 at 2:24 pm

    #4061670

    Avoid the news wherever possible, so no idea.

  • July 11, 2022 at 4:48 pm

    #4061718

    Steve Jones - SSC Editor wrote:

    Avoid the news wherever possible, so no idea.

    Good strategy Steve, if you miss it, then it's no longer news 😉

    😎

  • July 13, 2022 at 6:43 pm

    #4062909

    Question for the smart people, and the rest of you.

    Would you endorse or get behind the statement:

    Some deadlocks are healthy.

    or

    Some level of deadlocks is healthy.

    Or is more something like:

    Some level of deadlocks we can live with.

    I'm just surprised to hear deadlocks described as "healthy" in any terms. I'd argue, in a perfect world, any deadlock is bad. I simply don't see a place where using the word "healthy" to describe deadlocks is accurate. Certainly, there's a level below which they can be tolerated, and there's a level above which they're a major issue. That level is very much up to interpretation.

    What do you think?

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • July 13, 2022 at 6:51 pm

    #4062913

    Trick question, Grant.  I've been assured many, many times on this forum that the only acceptable answer to any question (other than "Is using AUTOSHRINK OK?") is: It Depends.

    😉

    Unless you're happy to have frequent occurrence of deadlock victims be your method of implementing resource contention (and here I'm imagining an application called Roman Gladiator, where the DB engine takes the frequent place of the emperor's thumb), then, no, "healthy" is not an adjective I would choose.  "Tolerable and infrequent" possibly.

    Then again, I'm not one of the smart people you were seeking with your question...

    🙂

    Rich

  • July 13, 2022 at 7:02 pm

    #4062920

    Grant Fritchey wrote:

    Question for the smart people, and the rest of you.

    Would you endorse or get behind the statement: Some deadlocks are healthy. or Some level of deadlocks is healthy.

    Or is more something like: Some level of deadlocks we can live with.

    I'm just surprised to hear deadlocks described as "healthy" in any terms. I'd argue, in a perfect world, any deadlock is bad. I simply don't see a place where using the word "healthy" to describe deadlocks is accurate. Certainly, there's a level below which they can be tolerated, and there's a level above which they're a major issue. That level is very much up to interpretation.

    What do you think?

    Some level of deadlocks we can live with.  And that's rarely and only in very specific cases.  As an example, we have a nighty purge process.  There are regular, not frequent, deadlocks.  The process captures the deadlock, and then tries again.  If it deadlocks three times, it logs what it "missed" to purge, and grabs them the next run.  If there are a significant number of missed records, an email gets sent.  We have not really had to do any intervention in years on this.

    I'm curious as to why a deadlock would be considered healthy?  One could possibly consider a deadlock healthy when they indicate something needs to be addressed.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • July 13, 2022 at 7:16 pm

    #4062922

    when the cost of remedying a deadlock is greater than the cost of the disruption caused by the deadlock then I'd just let the deadlocks happen.

    Since it is hard to know if that is the case, then I'd recommend trying to figure them out.

    412-977-3526 call/text

  • July 13, 2022 at 8:09 pm

    #4062947

    Thanks everyone for the feedback so far. All jives with my understanding. I've just never heard the phrase "healthy deadlocks" before, so I was curious what others thought.

     

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • July 17, 2022 at 4:47 pm

    #4064485

    Grant Fritchey wrote:

    Question for the smart people, and the rest of you.

    Would you endorse or get behind the statement: Some deadlocks are healthy. or Some level of deadlocks is healthy.

    Or is more something like: Some level of deadlocks we can live with.

    I'm just surprised to hear deadlocks described as "healthy" in any terms. I'd argue, in a perfect world, any deadlock is bad. I simply don't see a place where using the word "healthy" to describe deadlocks is accurate. Certainly, there's a level below which they can be tolerated, and there's a level above which they're a major issue. That level is very much up to interpretation.

    What do you think?

    Hah. Apply it to “you and another reaching for the last cake” and you’ll have your answer 😁

    Far away is close at hand in the images of elsewhere.
    Anon.

  • July 17, 2022 at 5:51 pm

    #4064496

    Grant Fritchey wrote:

    Question for the smart people, and the rest of you.

    Would you endorse or get behind the statement: Some deadlocks are healthy. or Some level of deadlocks is healthy.

    Or is more something like: Some level of deadlocks we can live with.

    I'm just surprised to hear deadlocks described as "healthy" in any terms. I'd argue, in a perfect world, any deadlock is bad. I simply don't see a place where using the word "healthy" to describe deadlocks is accurate. Certainly, there's a level below which they can be tolerated, and there's a level above which they're a major issue. That level is very much up to interpretation.

    What do you think?

    I'm not one of those that condone them.  I've just given up on me agonizing over them because no one else cares.  When I bring them up, people tell me that the "system handles and fixes or retries them" with "system" being their word for the code I've identified as a pretty serious performance issue (man, did I clean up that statement! 😀 ).  I've told them in the past that it will become an issue as the "systems" grow and the number of concurrent runs grows and slows.  Their comment is usually, "It's not an issue now and we don't have time to work on it.  We'll deal with it if and when it becomes an issue".

    And, BTW, it's recently started to become an issue.  😀

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • August 25, 2022 at 4:42 pm

    #4080591

    I know... I'm weird... I couldn't stop laughing as I read the following article about AI and on-prem.  I mean who knew that computationally intense processes on the cloud might be expensive, right? 😀  Who knew that long-haul connections might be intermittent, right? 😀

    https://www.protocol.com/enterprise/ai-machine-learning-cloud-data

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • August 25, 2022 at 5:58 pm

    #4080614

    Jeff Moden wrote:

    I know... I'm weird... I couldn't stop laughing as I read the following article about AI and on-prem.  I mean who knew that computationally intense processes on the cloud might be expensive, right? 😀  Who knew that long-haul connections might be intermittent, right? 😀

    https://www.protocol.com/enterprise/ai-machine-learning-cloud-data

    Of course, AI has a built-in response, "Let me think about it" whilst you pay for the computational resources...

    😎

    There is a misconception when it comes to the "Cloud", few realise that the name comes from the transparency of the billing or rather the lack thereof.

Viewing 15 posts - 65,986 through 66,000 (of 66,815 total)

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