In the editorial today we have interesting responses from our readers on the topics of Cloud Integration and Accidental DBA.
Cloud Integration
Frank:
first thanks for your ongoing insights via SSWUG. Last was about cloud integration.
One solution to integrate SQL (and other on premise applications) with the cloud is data replication.
What do you think about this solution, the Cloud Connector:
http://www.layer2.de/en/products/Pages/Cloud-Connector-for-SharePoint-2010-Office365.aspx
It’s not only for Office 365, it replicates almost any data source with almost any other, bi-directional if required.
Just let me know what you think about the idea and features.
Btw. it’s about cloud-to-cloud replication as well, e.g. Salesforce to SharePoint Online…
Editor:
I have not had an opportunity to look at the Cloud Connector. Perhaps our readers may have some feedback for
Accidental DBA – Managing Access Rights
Ryan:
Not only am I the true definition of the Accidental DBA, but also the Accidental Designer, BI Developer, and Programmer…
My biggest issue is that my position did not exist – it was developed for me to move into. Therefore, there was no one to train me – no one to bring me ‘up to speed’ on the stuff that the Executive Director of IT used to perform. Do you have a list of resources for DBA and BI?
I know there are tons of resources out there for the Accidental DBA, however repetitive they are – but there is very little out there regarding BI when it comes to administration.
Editor:
Business Intelligence (BI) platforms, especially in the Microsoft Stack, often have a relational database at the core. Even a BI database has tables that benefit from the same maintenance techniques such as index defragmentation, keeping statistics up to date, etc.
You also have the same issues with access rights, although they may be managed at more than one level, say as in the case of SharePoint.
So, in addition to everything you would do on an OLTP (Online Transaction Processing System) a BI system requires monitoring and managing of the data pipeline (importing, exporting data) as well as building cubes, etc.
Chris:
Often, developers or vendors will ask for "temporary" SA (or DBO) rights to fix an issue or do an install and promise to let the DBAs know when we can remove those rights. Unfortunately, they tend to "forget" to notify us when they’re done and nobody tries to pull the rights until they do their pre-production check. However, pulling them that late often jeopardizes the roll out schedule.
So, what we’ve done instead is build a standard maintenance plan that removes any non-standard rights every time a Full Backup runs. This plan is put on the servers as soon as SQL Server is installed before the server is even handed over to the developersvendors. This allows them enough time (a week or a day) to make their changes. If they need more time, they can re-request those rights with the understanding that they will be wiped out again the next time a full backup runs.
We have some good questions and tips today. If you want to get into the discussion, send your question or tip to
btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
So, You Want to be a DBA? (Part 3)
An important task is running a CheckDB on your database systems.
Featured White Paper(s)
Optimize SharePoint Storage with BLOB Externalization
Written by AvePoint
This document is intended to provide a comprehensive an… (read more)