January 19, 2016 at 12:58 pm
Just wondering if anyone knows if this would work.
We cannot use anything cloud..everything must be local.
Anybody tried using the stretch database feature with this as the azure cloud:
January 19, 2016 at 1:09 pm
I highly doubt it, and besides, there wouldn't be much point.
Stretch is so that you can move older (less used) rows out to cloud storage to reduce the storage you need locally.
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
January 19, 2016 at 1:18 pm
Understood.
In our case, we have to keep records forever. So, the tables get large but the older data is rarely used. But we still need access to the older records occasionally, audits, etc.
Having it the older records on a different box would free up some maintenance windows for us.
Isn't this the use that stretch was designed for?
January 19, 2016 at 1:45 pm
I don't think that would work given how stretch DB works under the covers, plus the fact that this private cloud solution doesn't cover all the Azure services/features/products.
The other reason for using this feature is to get data out of hot tables (those ones that are needed regularly) and into cooler tables that can still be accessed, but not necessarily with the same response time). So there are methods to make this sort of thing work better for you, but we'd need to know a bit more about the
"temperature" of your data and access patterns to make a recommendation.
Karen
January 19, 2016 at 1:57 pm
Okay, Fair enough. Thanks for the input. Didn't know there were some differences in the local version.
I think I can easily justify the use in our environment. I think it fits our needs.
Just didn't know if anyone had actually tried it.
Is there any other solution for using stretch with a local server?
January 19, 2016 at 2:19 pm
Stretch specifically? No.
But some ways that teams archive data are partitioning, manually moving data to another table and using a view over the multiple tables, or backing up data and restoring on demand (sometimes hours or days later). It so depends on your business requirements. I know others might pipe in here with some generic recommendations.
January 19, 2016 at 2:20 pm
Partitioning. Stretch is kinda 'automatic partitioning', so you can partition the table, switch out older data (partition at a time) into a standalone table. Once it's not in the main table (the one that gets inserts and gets used in queries), you can do an insert...select to copy the data to another database then truncate the standalone table. You could then move that other DB to another server
It's manual, it takes some work, but it may work, and most of it can be automated.
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
January 19, 2016 at 3:16 pm
krypto69, your description fits StretchDB's scenario very nicely. However, as Karen indicated, Azure Pack doesn't have all services available with the public Azure service. Many of them are temporary, that means they will eventually make it to Azure Pack. I don't see any reason why StretchDB cannot support Azure Pack.
January 19, 2016 at 3:52 pm
I'm trying to look up the detailed specs of azure pack. Currently stretch DB requires the target SQL DB to be v12.
And I see that they did a recent release announcement for Azure Pack around SQL DB functionality. But I'm on my phone now and looking up specs is painful.
The other great thing about Azure offerings is that they are always being improved 😉
January 21, 2016 at 9:04 am
Thanks everyone for the input.
February 12, 2016 at 8:40 am
I think the idea of Stretch with Azure pack on prem is great. This allows me to use older, even slower hardware, consolidated together as a "cloud" in my DC, and automatically move data from my primary db. I hope this works with Azure Pack.
I did find this and am watching. It appears to expose your on premise SQL Server as a service. I'm not sure this would work (yet) with stretch, as Stretch doesn't appear to work from on premise SQL Server to on premise SQL Server. Maybe that is coming in SQL 2016 or vNext.
February 12, 2016 at 1:17 pm
Thanks Steve.
I hope MS considers this a need. I'm sure there are plenty of other folks out there that can't use the cloud for various reasons.
February 12, 2016 at 1:58 pm
Stack.
Older and slower, as long as server meets these requirements:
12 physical cores
96 GB RAM
Windows 2012 certified NIC
and more...
Not that people haven't already figured out how to bypass some of the checks. But that can be an iffy thing for production environments.
February 12, 2016 at 4:56 pm
I finished the video, and it appears as of now, the Azure pack merely sits over your existing instances, so I'm pretty sure Stretch DB won't work here. This is to allow you to really give self-service database creation to users over existing 2008/2012/2014 instances.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply