Are the posted questions getting worse?

  • Ed Wagner (12/18/2014)


    Greg Edwards-268690 (12/18/2014)


    Brandie Tarvin (12/18/2014)


    So, I'm curious. Anyone have any major projects that people want before the end of the year?

    We have a business user that keeps asking for X fix, which I already have coded actually. But our SDLC requires the QA team to do thorough testing and none of them have the bandwidth until mid-January, which makes this a February release. None of which stops the BU from asking me if I can put the code into production NOW PLEASE.

    What's worse is that he should know better given what impatience has done to his processes before. But some lessons just don't seem to stick.

    When something goes into production, expedited and skipping some testing, who is to blame when there are issues?

    Likely you, not the business.

    So they usually end up with little risk in pushing to short circuit the process.

    Business needs to make a case to support more resources at the bottleneck.

    All too often, they expect IT to be doing this.

    When they actually might be in a better position to quantify benefits to the business.

    Hopefully they are part of the QA process, so the more they push, the more they end up being part of the resources needed to speed things up.

    They selectively ignore requests for testing, never do the testing they're supposed to do and keep pushing for the production release. When things to awry, they don't know what happened or why things didn't work the way they wanted them to. It's just what they asked for, but not what they wanted. It isn't until later that they say they "didn't have time to test" with the deadline already here. Pay no attention to the fact that they were asking for quotes for new work when they were supposed to be testing.

    This is one reason why I like to log *everything*.

    User: "Hey, when's project wombat going live <bigwig> is asking I'll have to tell him the delay's with you"

    Dev: "When you've tested it"

    User: "Oh that's done"

    Dev: "Funny that - the log says you've done none"

    User "You're SPYING on us?!"

    Dev: "Aye - I'd bear that in mind ... "

    (redacted version of actual conversation - there was language Steve J would take me to task for posting here)

    I'm a DBA.
    I'm not paid to solve problems. I'm paid to prevent them.

  • Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

  • jasona.work (12/19/2014)


    Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

    I think it had a lot to do with proximity and speed of response. The closer the processors are to one another, the faster they can communicate with one another. If they're part of the same unit, they're very close and have no intermediary (the motherboard) between them to slow things down.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • Stefan Krzywicki (12/19/2014)


    jasona.work (12/19/2014)


    Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

    I think it had a lot to do with proximity and speed of response. The closer the processors are to one another, the faster they can communicate with one another. If they're part of the same unit, they're very close and have no intermediary (the motherboard) between them to slow things down.

    Don't confuse things with details!

    :hehe:

    But yes, interconnect speed likely played a very big part in the development of multi-cores. Imagine the difficulties in keeping 4+ single core CPUs in-sync when they're separated by a couple inches on the motherboard vs keeping them in-sync when they're only a couple fractions of a millimeter apart on a CPU die. Plus there would be cost savings from various things that could be shared between the cores, rather than having each reproduces on each CPU.

  • jasona.work (12/19/2014)


    Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

    Not directly related, but something to maybe note.

    Numa architecture in the machines kind of layers RAM in a similar fashion.

    You may have 2 main banks, each tied to a socket. And specific memory (size and speed) optimized to work together.

    So memory - and upgrade path - may be a consideration.

    You may want to review some of the other licensing - especially for a virtual machine.

    Host and how many cores - not what may be allocated to an instance - is the driver.

    You can imagine the licensing true up costs, especially if you have multiple 8 or more core procs in a machine.

    I liked the old licensing model better - it was much clearer and easier to understand.

  • jasona.work (12/19/2014)


    (I think some of the L2 and L1 cache, various other bits and bobs)

    Each core has it's own L1, at least with the Intel processors. L2 is 'shared' (kinda, one core can't flush the entire of L2), L3 if present as well.

    Reason multiple cores is better than multiple processors is to do with the inter-core communication. With them really close together, there's less delay in communications between them.

    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
  • Greg Edwards-268690 (12/19/2014)


    I liked the old licensing model better - it was much clearer and easier to understand.

    I couldn't agree more if I tried. We're trying to gather licensing information now and it's to the point where the sales guy doesn't even know. He has an expert in SQL licensing he has to consult with every question I ask. They've made things unnecessarily complicated. One thing is certain...In the end, we'll pay more. It shouldn't have to be so complicated.

  • Greg Edwards-268690 (12/19/2014)


    jasona.work (12/19/2014)


    Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

    Not directly related, but something to maybe note.

    Numa architecture in the machines kind of layers RAM in a similar fashion.

    You may have 2 main banks, each tied to a socket. And specific memory (size and speed) optimized to work together.

    So memory - and upgrade path - may be a consideration.

    You may want to review some of the other licensing - especially for a virtual machine.

    Host and how many cores - not what may be allocated to an instance - is the driver.

    You can imagine the licensing true up costs, especially if you have multiple 8 or more core procs in a machine.

    I liked the old licensing model better - it was much clearer and easier to understand.

    Unfortunately we're not going to get virtual machines this time around. Corporate doesn't have the design ready and we need the servers yesterday to respond to a vendor upgrade.

    At least this time around we have a vendor upgrading before us instead of two years after us. That's got to count for something, right?

    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 (12/19/2014)


    Greg Edwards-268690 (12/19/2014)


    I liked the old licensing model better - it was much clearer and easier to understand.

    I couldn't agree more if I tried. We're trying to gather licensing information now and it's to the point where the sales guy doesn't even know. He has an expert in SQL licensing he has to consult with every question I ask. They've made things unnecessarily complicated. One thing is certain...In the end, we'll pay more. It shouldn't have to be so complicated.

    I ran into the same thing a few years ago.

    I knew more than our Rep.

    And corporate didn't listen to me, and heard a true up horror story after I left.

    Here's a blast from the past -

    remember how they used to market the processor based licensing as a competitive advantage?

    and VM licensing too?

  • Brandie Tarvin (12/19/2014)


    Greg Edwards-268690 (12/19/2014)


    jasona.work (12/19/2014)


    Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Actually, I wouldn't be surprised if that was about the thought process when the engineers came up with the first multi-core CPU...

    So, yes, that's a pretty decent way to think of it.

    πŸ˜€

    Not directly related, but something to maybe note.

    Numa architecture in the machines kind of layers RAM in a similar fashion.

    You may have 2 main banks, each tied to a socket. And specific memory (size and speed) optimized to work together.

    So memory - and upgrade path - may be a consideration.

    You may want to review some of the other licensing - especially for a virtual machine.

    Host and how many cores - not what may be allocated to an instance - is the driver.

    You can imagine the licensing true up costs, especially if you have multiple 8 or more core procs in a machine.

    I liked the old licensing model better - it was much clearer and easier to understand.

    Unfortunately we're not going to get virtual machines this time around. Corporate doesn't have the design ready and we need the servers yesterday to respond to a vendor upgrade.

    At least this time around we have a vendor upgrading before us instead of two years after us. That's got to count for something, right?

    Always nice to have vendors supporting something more current.

    VM's are good, but there is a learning curve.

    Especially if you try to crowd too much onto them, and don't understand how to troubleshoot a performance issue.

    VM's do offer some pretty good options for scaling and recovering.

    So it is worth the learning curve.

  • ... Mark one off, 71 days on the calendar to go. 71 days on the calendar to go, 71 days to go, ...

  • Merry Christmas and Happy Holidays, everyone.

    I'll be gone after tomorrow, heading away for a week. Everyone behave.

  • Steve Jones - SSC Editor (12/19/2014)


    Merry Christmas and Happy Holidays, everyone.

    I'll be gone after tomorrow, heading away for a week. Everyone behave.

    Have a great holiday Steve. We are heading to the Bahamas for week right after Christmas.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Sean Lange (12/19/2014)


    Steve Jones - SSC Editor (12/19/2014)


    Merry Christmas and Happy Holidays, everyone.

    I'll be gone after tomorrow, heading away for a week. Everyone behave.

    Have a great holiday Steve. We are heading to the Bahamas for week right after Christmas.

    Merry Christmas to you both and enjoy your vacations.

  • Brandie Tarvin (12/19/2014)


    Trying another rephrase to see if I understand this correctly.

    So basically instead of creating multiple physical processors like memory makers create sticks of RAM, some bright soul thought to "weld" multiple processors into one "container" and hook them together. That way motherboards still only needed one (or two) slots for a CPU but servers and PCs could get the benefits of having multiple processors.

    Yes? No? Maybe?

    Yes. Processor is the socket and cores is the number of cpus on the socket or that can fit in the socket. Cores are smaller, but to save space, it was easier to bring those cores together to fit in the same socket.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

Viewing 15 posts - 46,666 through 46,680 (of 66,712 total)

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