June 30, 2014 at 4:50 am
Hi. I'm having my first foray into SQL Server in the cloud and I'm not having any fun at all. I really need some hand holding until I get going. I've years of experience of locally hosted SQL Servers (that live in actual metal boxes that you can touch), accessed through SSMS - all nice and easy, but this is new and uncomfortable and I honestly don't understand it.
We've got this CRM system and I've been asked to make the data accessible, useable, warehoused etc. Trouble is that the data is 'in the cloud' but I don't know if its in Azure or something else.
I've been given an ODBC connection to our data. I've built an SSIS package that uses the ODBC connection and can at least access the data and pull it into a local SQL Server and from there I'm back in my comfort zone.
My issue is that its so bloody slow. This SSIS package is taking around 30 minutes to connect to the database, and import the data from just one single table. There's only 14k rows.
There's also the issue of the database itself having been designed by an idiot so the tables have stupid numbers of columns and I'll bet that nothing's indexed. I don't know why they bother having a database developer on site (me) and then let Dave from IT build the database but that's a rant for another day.
If data in the cloud is supposed to be the new big thing, then I can't be doing it right. So here are my questions:
Is ODBC the right way to connect?
How can I make it quicker?
How can I check things like indexing etc.?
If my questions seem stupid, then I apologise. Feel free to insult me at your leisure.
Thanks for reading, and (hopefully) giving me some pointers.
June 30, 2014 at 9:32 am
I don't know that I'd use ODBC. I'd rather go for as direct a connection as possible. You should be able to make a direct connection if it's Microsoft Azure SQL Database or if it's a VM on Azure.
To look at the structures, etc., you can use SSMS. Whatever connection string you have in ODBC should translate well. Once in there, from a database stand point, MASD is just a database for the most part. Clustered indexes, nonclustered indexes, etc. If you are hitting resource issues, you can pay for more resources. It's really hard to make a whole lot more suggestions without knowing what it is that we're talking about, hosted VMs, MASD, Amazon, something else? Each has different approaches to resolving issues. Each has different issues that need to be resolved.
All cloud access from your client is likely to be slower than having metal there on site with you.
"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
September 5, 2014 at 7:53 am
Q. is WASD now called MASD?
I thought the correct name Windows Azure SQL Database...(behind the times obviously!) 🙂
September 5, 2014 at 8:43 am
SQL Swerver (9/5/2014)
Q. is WASD now called MASD?I thought the correct name Windows Azure SQL Database...(behind the times obviously!) 🙂
Nope. The dropped the Windows name from Azure. They don't want it associated with the OS.
"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
September 5, 2014 at 9:57 am
Understood. It made me chuckle when I read this excerpt from Wikipedia and reminded me of Prince, <symbol>, AFKAP, etc.
"Microsoft Azure SQL Database (formerly SQL Azure, SQL Server Data Services, SQL Services, Windows Azure SQL Database) is a cloud-based service from Microsoft offering data-storage capabilities (similar to Amazon Relational Database Service) as a part of the Azure Services Platform."
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply