We Have a Date

  • kevin77 - Thursday, September 28, 2017 10:39 AM

    From the editorial,

    ...as I'm not completely sure that containers are the best choice for database systems, but I am considering them as a possible replacement for VMs.

    Would you mind elaborating on that some more,either here or in another editorial.  Just about all of my knowledge about containers comes from you mentioning them.  But I'm a little confused by that statement.  If a container is good enough to replace an entire VM, and people run database servers in VMs, then...then why not a container for a database system?

    Slightly concerned about scaling here. Early in the VM era, we had issues with performance, especially IO, but also memory. Still have some issues here. I'm not sure how containers deal with this. For this site, a few cores (4? 8?), maybe I don't care.

    Certainly storage needs to be outside of the container, so there's the interactions with in v out of container storage, but the idea of being able to restart a container, or perform a CU upgrade must more quickly with a container than booting a phys server or VM is interesting.

  • Sean Lange - Thursday, September 28, 2017 10:41 AM

    jasona.work - Thursday, September 28, 2017 10:28 AM

    Sean Lange - Thursday, September 28, 2017 9:57 AM

    Woohoo. And just a few weeks after we have finally migrated the last of our production databases off of 2005. Sadly we only upgraded to 2014 but hey at least our production databases are at least using a currently supported version. :crazy:

    Don't feel too bad, I'm *almost* done getting all my servers off 2008R2 to 2014.
    I had someone ask me yesterday when we'd be going to 2017, my answer was "only when someone comes to me and says there's this really neat new feature in 2017 that we just HAVE to have!"
    Then it'll probably still be 6-9 months just to get the server stood up and installed, another several months (or more) to get SSMS17 approved for use on our network, plus a couple months for the desktop people to figure out how to install it, get that approved and tested...

    The biggest win is that we are no longer replicating data from our flat file data source from the AS400 to sql server. We couldn't even use sql server replication, we instead had to use a third party replication tool designed for replicating that type of data.

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

  • The upcoming PASS conference in Seattle this November will be my first. Looking at the line-up of presentation topics and speakers; I can tell it's going to be a great year to attend.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Lynn Pettis - Thursday, September 28, 2017 10:44 AM

    Eric M Russell - Thursday, September 28, 2017 10:42 AM

    All you guys with SQL Server 2014 certification listed on your resume; you're like 2 releases behind already. Try to keep up. 😉

    We are still on SQL Server 2012.  Not looking at upgrading at the moment, but hoping to soon.

    We're currently running on scores of 2008 / 2008 R2 / 2012 / 2014 / 2016 / Azure instances. Also a handful of SQL Server 2005 instances supporing a vendor app about to be pushed under a bus. OK, that's just production. Across DEV, QA, and PROD; it's a couple hundred servers. I'm sure at this very moment someone is installing both Linux and 2017 on a development server.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell - Thursday, September 28, 2017 10:49 AM

    The upcoming PASS conference in Seattle this November will be my first. Looking at the line-up of presentation topics and speakers; I can tell it's going to be a great year to attend.

    Wish I could go, finances just aren't there.  I enjoyed PASS 2015.  Have fun!

  • Summer90 - Thursday, September 28, 2017 11:18 AM

    Didn't have much to say on this I take it? 😀

    _______________________________________________________________

    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/

  • jasona.work - Thursday, September 28, 2017 10:47 AM

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Shush, you weren't meant to tell anyone we're still doing that!

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

  • Thom A - Thursday, September 28, 2017 11:39 AM

    jasona.work - Thursday, September 28, 2017 10:47 AM

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Shush, you weren't meant to tell anyone we're still doing that!

    So I shouldn't mention the data getting loaded in from flat files that are sent in a weird compressed format that takes a custom archive application to uncompress them and stick them back together in multiple SQL Agent job steps?

  • jasona.work - Thursday, September 28, 2017 1:44 PM

    Thom A - Thursday, September 28, 2017 11:39 AM

    jasona.work - Thursday, September 28, 2017 10:47 AM

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Shush, you weren't meant to tell anyone we're still doing that!

    So I shouldn't mention the data getting loaded in from flat files that are sent in a weird compressed format that takes a custom archive application to uncompress them and stick them back together in multiple SQL Agent job steps?

    But just think of all the disk space they've been saving. Back in 1987 when the export process was created, it was like $50,000 per GB on the mainframe, and the developer's PC only had a 10 MB hard disk.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • jasona.work - Thursday, September 28, 2017 1:44 PM

    Thom A - Thursday, September 28, 2017 11:39 AM

    jasona.work - Thursday, September 28, 2017 10:47 AM

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Shush, you weren't meant to tell anyone we're still doing that!

    So I shouldn't mention the data getting loaded in from flat files that are sent in a weird compressed format that takes a custom archive application to uncompress them and stick them back together in multiple SQL Agent job steps?

    You are actually almost quoting how one of my systems at the office works (replace SQL Agent with BULK INSERT)... I'm not sure if to be worried or upset at the fact that that's how it works still in 2017. :crying:

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

  • jasona.work - Thursday, September 28, 2017 10:47 AM

    Sean Lange - Thursday, September 28, 2017 10:41 AM

    jasona.work - Thursday, September 28, 2017 10:28 AM

    Sean Lange - Thursday, September 28, 2017 9:57 AM

    Woohoo. And just a few weeks after we have finally migrated the last of our production databases off of 2005. Sadly we only upgraded to 2014 but hey at least our production databases are at least using a currently supported version. :crazy:

    Don't feel too bad, I'm *almost* done getting all my servers off 2008R2 to 2014.
    I had someone ask me yesterday when we'd be going to 2017, my answer was "only when someone comes to me and says there's this really neat new feature in 2017 that we just HAVE to have!"
    Then it'll probably still be 6-9 months just to get the server stood up and installed, another several months (or more) to get SSMS17 approved for use on our network, plus a couple months for the desktop people to figure out how to install it, get that approved and tested...

    The biggest win is that we are no longer replicating data from our flat file data source from the AS400 to sql server. We couldn't even use sql server replication, we instead had to use a third party replication tool designed for replicating that type of data.

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Heh... well, at least its not some tag delimited atrocity like XML, JSON, etc. 😉

    --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)

  • jasona.work - Thursday, September 28, 2017 1:44 PM

    Thom A - Thursday, September 28, 2017 11:39 AM

    jasona.work - Thursday, September 28, 2017 10:47 AM

    Heh
    One of my customers still pulls in data, in flat files, from a mainframe...

    Shush, you weren't meant to tell anyone we're still doing that!

    So I shouldn't mention the data getting loaded in from flat files that are sent in a weird compressed format that takes a custom archive application to uncompress them and stick them back together in multiple SQL Agent job steps?

    Heh... almost as bad as XML, then. 😉

    --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)

  • The Data Tuning Adviser is going to recommend columnstore indexes for me? October 2nd can't come soon enough! </sarcasm>

    It's cool to finally see some new T-SQL commands. TRIM and CONCAT_WS are not game changers but  I was excited about STRING_AGG and TRANSLATE. Unfortunately, as was the case with string_split, STRING_AGG and TRANSLATE were poorly implemented IMHO. 

    I've been using 2017 SSMS for a while and I have seen some cool changes to the execution plans.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • Alan.B - Thursday, September 28, 2017 5:07 PM

    The Data Tuning Adviser is going to recommend columnstore indexes for me? October 2nd can't come soon enough! </sarcasm>

    It's cool to finally see some new T-SQL commands. TRIM and CONCAT_WS are not game changers but  I was excited about STRING_AGG and TRANSLATE. Unfortunately, as was the case with string_split, STRING_AGG and TRANSLATE were poorly implemented IMHO. 

    I've been using 2017 SSMS for a while and I have seen some cool changes to the execution plans.

    Really?... STRING_AGG (or at least the functionality) has been a wish list for quite awhile now. I hate XML and I always feel a bit "unclean" every time I use FOR XML PATH('').
    Is it not as fast as XML (or JSON)?

Viewing 15 posts - 16 through 30 (of 31 total)

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