Are the posted questions getting worse?

  • Thom A - Monday, November 20, 2017 12:11 PM

    I can't believe that topic about the system DB IDs is still going. O.o

    Probably unwise of me, but after reading so much nonsense I could not resist stepping in and provinding a real answer. I don't expect it to help but at least I tried.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Sean Lange - Monday, November 20, 2017 1:00 PM

    Ed Wagner - Monday, November 20, 2017 12:39 PM

    Eirikur Eiriksson - Monday, November 20, 2017 12:13 PM

    Trying to have dinner but cannot stop laughing, my daughters think I'm going mad:crazy:
    😎

    Step away from the computer, phone or whatever it is you're using to read the dribble.  I'll admit it made me laugh as well.

    I read that and also need a new keyboard. I have no idea what got that guy's panties tied in a knot but my gosh. He sure threw around upping the point count a lot in otherwise absolutely useless posts. I have seen several posts by him over time and they are all quite strange.

    Including an article on string splitting that used the XML approach.  It was slow unless all the data was the same and, oh yeah, it didn't work.  IIRC, it dropped 1 row for every 5000.

  • Hugo Kornelis - Monday, November 20, 2017 1:20 PM

    Thom A - Monday, November 20, 2017 12:11 PM

    I can't believe that topic about the system DB IDs is still going. O.o

    Probably unwise of me, but after reading so much nonsense I could not resist stepping in and provinding a real answer. I don't expect it to help but at least I tried.

    I said the same earlier, just briefer.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster - Monday, November 20, 2017 2:02 PM

    Hugo Kornelis - Monday, November 20, 2017 1:20 PM

    Thom A - Monday, November 20, 2017 12:11 PM

    I can't believe that topic about the system DB IDs is still going. O.o

    Probably unwise of me, but after reading so much nonsense I could not resist stepping in and provinding a real answer. I don't expect it to help but at least I tried.

    I said the same earlier, just briefer.

    Oops.
    Guess I am now busted. Yes I admit, at one point I just started scrolling and glancing over all the posts.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Hugo Kornelis - Monday, November 20, 2017 2:49 PM

    GilaMonster - Monday, November 20, 2017 2:02 PM

    Hugo Kornelis - Monday, November 20, 2017 1:20 PM

    Thom A - Monday, November 20, 2017 12:11 PM

    I can't believe that topic about the system DB IDs is still going. O.o

    Probably unwise of me, but after reading so much nonsense I could not resist stepping in and provinding a real answer. I don't expect it to help but at least I tried.

    I said the same earlier, just briefer.

    Oops.
    Guess I am now busted. Yes I admit, at one point I just started scrolling and glancing over all the posts.

    Don't worry, everything I've said in that thread has been ignored, including info based on research I did for an article.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster - Monday, November 20, 2017 11:54 PM

    Hugo Kornelis - Monday, November 20, 2017 2:49 PM

    GilaMonster - Monday, November 20, 2017 2:02 PM

    Hugo Kornelis - Monday, November 20, 2017 1:20 PM

    Thom A - Monday, November 20, 2017 12:11 PM

    I can't believe that topic about the system DB IDs is still going. O.o

    Probably unwise of me, but after reading so much nonsense I could not resist stepping in and provinding a real answer. I don't expect it to help but at least I tried.

    I said the same earlier, just briefer.

    Oops.
    Guess I am now busted. Yes I admit, at one point I just started scrolling and glancing over all the posts.

    Don't worry, everything I've said in that thread has been ignored, including info based on research I did for an article.

    Not by everyone.  Aside from the drama and "hissy fits" there, I see value in some of the posts.  I get the multiple threads and why some would take longer to start than others.  I also see why master and resource come first and why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only question I have is about the trace flags.  When are they applied?  I'd think they would be applied in the .exe before master, but haven't researched it like you have.

    Yes, I know about posting a technical question in The Thread, but I'm not going to get drawn into the drama.

  • Ed Wagner - Tuesday, November 21, 2017 5:34 AM

     why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only time the TempDB files are created is if they don't exist. Otherwise they're resized and the contents of Model are copied across (mostly, don't put several GB of tables into model)

    The only question I have is about the trace flags.  When are they applied?  I'd think they would be applied in the .exe before master, but haven't researched it like you have.

    No idea. Likely depends on the traceflag. Some have to be applied early (eg the one that prevents any DB other than master from being started), some are only needed after the server is available (eg 1222)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster - Tuesday, November 21, 2017 10:23 AM

    Ed Wagner - Tuesday, November 21, 2017 5:34 AM

     why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only time the TempDB files are created is if they don't exist. Otherwise they're resized and the contents of Model are copied across (mostly, don't put several GB of tables into model)

    Are you sure?
    Asking because (1) sys.databases always has the last restart date and time as create_date of tempdb; and (2) last change date in the file system for a running instance is startup time for tempdb files as opposed to last shutdown time for other databases; and (3) create date in the file system for tempdb files is same as startup time. In other words, this all suggests that the files are deleted and then cleanly allocated.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Hugo Kornelis - Tuesday, November 21, 2017 10:57 AM

    GilaMonster - Tuesday, November 21, 2017 10:23 AM

    Ed Wagner - Tuesday, November 21, 2017 5:34 AM

     why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only time the TempDB files are created is if they don't exist. Otherwise they're resized and the contents of Model are copied across (mostly, don't put several GB of tables into model)

    Are you sure?
    Asking because (1) sys.databases always has the last restart date and time as create_date of tempdb; and (2) last change date in the file system for a running instance is startup time for tempdb files as opposed to last shutdown time for other databases; and (3) create date in the file system for tempdb files is same as startup time. In other words, this all suggests that the files are deleted and then cleanly allocated.

    The created date would be changed if the files are physically dropped and recreated.  I am only seeing the modified date changing when SQL Server is restarted.

  • Lynn Pettis - Tuesday, November 21, 2017 11:03 AM

    Hugo Kornelis - Tuesday, November 21, 2017 10:57 AM

    GilaMonster - Tuesday, November 21, 2017 10:23 AM

    Ed Wagner - Tuesday, November 21, 2017 5:34 AM

     why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only time the TempDB files are created is if they don't exist. Otherwise they're resized and the contents of Model are copied across (mostly, don't put several GB of tables into model)

    Are you sure?
    Asking because (1) sys.databases always has the last restart date and time as create_date of tempdb; and (2) last change date in the file system for a running instance is startup time for tempdb files as opposed to last shutdown time for other databases; and (3) create date in the file system for tempdb files is same as startup time. In other words, this all suggests that the files are deleted and then cleanly allocated.

    The created date would be changed if the files are physically dropped and recreated.  I am only seeing the modified date changing when SQL Server is restarted.

    I see the same thing in the file system, but I only checked one server.  The create date is February 2013 and the server has most certainly been rebooted since then.
    The sys.databases.create_date and file system modified date both show the last reboot time.
    So what Gail said holds true.  Thanks to both Gail for the info and Lynn for the good test.  I'd know about sys.databases, but never checked the file system dates.

  • So this may have already been posted to The Thread, but in case it hasn't...

    ...How dependent are you on your morning coffee / caffeine buzz? There's a better solution...

    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.

  • Ed Wagner - Tuesday, November 21, 2017 11:17 AM

    Lynn Pettis - Tuesday, November 21, 2017 11:03 AM

    Hugo Kornelis - Tuesday, November 21, 2017 10:57 AM

    GilaMonster - Tuesday, November 21, 2017 10:23 AM

    Ed Wagner - Tuesday, November 21, 2017 5:34 AM

     why tempdb shows up later - I'm thinking it depends on how long it takes to create the files and size them up to the initial size.

    The only time the TempDB files are created is if they don't exist. Otherwise they're resized and the contents of Model are copied across (mostly, don't put several GB of tables into model)

    Are you sure?
    Asking because (1) sys.databases always has the last restart date and time as create_date of tempdb; and (2) last change date in the file system for a running instance is startup time for tempdb files as opposed to last shutdown time for other databases; and (3) create date in the file system for tempdb files is same as startup time. In other words, this all suggests that the files are deleted and then cleanly allocated.

    The created date would be changed if the files are physically dropped and recreated.  I am only seeing the modified date changing when SQL Server is restarted.

    I see the same thing in the file system, but I only checked one server.  The create date is February 2013 and the server has most certainly been rebooted since then.
    The sys.databases.create_date and file system modified date both show the last reboot time.
    So what Gail said holds true.  Thanks to both Gail for the info and Lynn for the good test.  I'd know about sys.databases, but never checked the file system dates.

    Huh? That's weird. I though I saw the create date equal to the last startup date so I was flabbergasted by your replies. Went back to the filesystem to make a screenshot ... and found that I must have looked wrong or so. Create date is indeed much longer ago.
    Thanks for putting me straight!


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Brandie Tarvin - Tuesday, November 21, 2017 11:51 AM

    So this may have already been posted to The Thread, but in case it hasn't...

    ...How dependent are you on your morning coffee / caffeine buzz? There's a better solution...

    He hasn't had my coffee yet :alien:
    😎

  • Brandie Tarvin - Tuesday, November 21, 2017 11:51 AM

    So this may have already been posted to The Thread, but in case it hasn't...

    ...How dependent are you on your morning coffee / caffeine buzz? There's a better solution...

    I prefer dropping an entire database, that *REALLY* gets the blood moving!

  • Brandie Tarvin - Tuesday, November 21, 2017 11:51 AM

    So this may have already been posted to The Thread, but in case it hasn't...

    ...How dependent are you on your morning coffee / caffeine buzz? There's a better solution...

    How about uninstalling a SQL Server instance from the wrong server?
    Been there, done that.

Viewing 15 posts - 60,451 through 60,465 (of 66,000 total)

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