The first thing to understand is that all linked server objects are accessible by everyone in the public database role (normally everybody). So what you are doing when you configure the security for a linked server is determining what the security context of the login will be on the remote server. The permissions of that login on the remote server will ultimately determine what the user can and can’t do.

A 750-point Health Check from SQL Solutions Group includes a security audit.

Find out how healthy your SQL Server estate really is.

Learn More

What we will be looking at is the Security tab of the linked server dialog. We’ll also look at the system stored procedures being executed behind the scenes. You can see these yourself by clicking the Script button after configuring the security in the GUI.

Default Behavior for Unmapped Logins

The top part of the dialog box allows us to map local logins to remote logins. This is fairly straightforward and not where the problem usually lies so we’re going to focus on what happens if there is not a mapped login.

We’ll look at the options one at a time.

Not be made

In this case, all that is done is to create the linked server with no login behavior specified. Without any mapped logins, the linked server is useless.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SQL Server'

If we try to execute a linked server query, we get the following results:

Source code
   
select name from SERVER1.master.sys.databases

Msg 18456, Level 14, State 1, Line 7
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

It tried to make an anonymous connection to the remote server which thankfully did not work.

Be made without using a security context

In this case, it explicitly creates a mapped login of NULL with @useself = ‘False’. In other words we are explicitly telling it not to pass a security context to the remote server whereas in the first option it tried an anonymous connection.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SQL Server', @provider=N'SQLNCLI11', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SERVER1',@useself=N'False',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

Let’s see what happens when we execute the query here.

Source code
   
select name from SERVER1.master.sys.databases

OLE DB provider "SQLNCLI11" for linked server "SERVER1" returned message "Invalid authorization specification".
Msg 7399, Level 16, State 1, Line 7
The OLE DB provider "SQLNCLI11" for linked server "SERVER1" reported an error. Authentication failed.
Msg 7303, Level 16, State 1, Line 7
Cannot initialize the data source object of OLE DB provider "SQLNCLI11" for linked server "SERVER1".

This option is more secure than the first one simply because it would not work even if the anonymous login worked on the remote server.

Be made using the login’s current security context

In this case, it is going to pass the security context of the local login to the remote login. If you have to have an option to connect without a mapped login, this is the best option. Note that the call to sp_addlinkedsrvlogin is almost the same as the last one. The only difference is that the @useself parameter is True.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SERVER1', @provider=N'SQLNCLI11', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SERVER1',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

Let’s see what happens when we execute the query here.

Source code
   
select name from SERVER1.master.sys.databases

It worked this time. The login used on the local server also existed on the remote server so the user connected as if they were directly connecting to the remote server. One thing to note is that with standard logins, this will only work if the login name AND password are the same on both instances. If the login name is the same and the password is different you will get the following error:

Msg 18456, Level 14, State 1, Line 11
Login failed for user 'UserA'.

For this reason, this is a lot easier to deal with when using Active Directory accounts. As long as the AD-based login has permission on both instances it should work just fine, with one caveat. Depending on the configuration of the AD environment you’re in, you may run in what is known as the Kerberos Double Hop issue. Typically you’d be going from a user’s workstation to the local server to the remote server. So two hops. A full discussion of this is beyond the scope of this article but suffice it to say that Kerberos delegation must be properly configured in the environment for this to work.

Be made using this security context

This is unfortunately both the most commonly used and the least secure way to address the security configuration of your linked server. What we are saying here is that every user who uses the linked server will be authenticated on the remote server using the credentials provided here. This is RARELY going to be the right thing to do in a secure environment. A user with public on the local server and nothing else will connect to the remote server using this login’s permissions which are usually higher than that. I’ve seen more than one environment using an account like linkedserver that exists and is a sysadmin on every server!

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'RKLAPTOPSS', @provider=N'SQLOLEDB', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname = N'SERVER1', @locallogin = NULL , @useself = N'False', @rmtuser = N'UserA', @rmtpassword = N'password'

I won’t bother executing the query for this one because obviously it will work.

Remote Login Mapping

We didn’t spend a lot of time on mapped logins because that is fairly straightforward. We can map a local login to a remote login, providing the login name and password on the remote server. This is useful if we can’t control the login name and password on the remote server. It is also useful if we want to control exactly who on the local server can use the remote server. If you have logins mapped here and are using one of the first two options for the default behavior, only these users will have access to the remote server via the linked server.

The Impersonate option is just what it sounds like. This is effectively the same as the Be made using the login’s current security context but applies to a specific login, not all of them.

In this example, the only users who can access the remote server are UserA and UserB. For UserA, we have specified the login name and password on the remote server. UserB has the same login name and password on the remote server so impersonation can be used.

The post Security Configuration for Linked Servers appeared first on SQL Solutions Group.

The specs Google outlined for Cloud SQL are nothing to sneeze at:

• Up to 30 TB of storage
• Up to 60,000 IOPS
• Up to 416 GB memory per instance
• Greater than 99.95% availability
• Automated backups, replication, patches and updates

Clearly the folks at Google are tired of playing third fiddle to AWS and Azure and wanted to up the ante at the cloud-based computing poker table. Google is also going to great lengths to differentiate it’s offering. As Ron Miller at TechCrunch put it, “Google is trying to position itself in the same way as any cloud vendor going after AWS. They are selling themselves as the hybrid cloud company that can help with your digital transformation.”

Google also announced Anthos as a tool to manage workloads. As explained by Urs Hölzle, senior VP for technical infrastructure, “We will support Anthos and AWS and Azure as well, so people get one way to manage their application and that one way works across their on-premise environments and all other clouds.”

Additionally, he said, “I can’t really stress how big a change that is in the industry, because this is really the stack for the next 20 years, meaning that it’s not really about the three different clouds that are all randomly different in small ways. This is the way that makes these three cloud — and actually on-premise environments, too — look the same.”

Is SQL for Microsoft SQL Server right for your business?

Translation: A single managed service for deploying across clouds and no worries about APIs. And it’s far from vaporware: Google has lined up more than 30 hardware and software partners to pull it off. Put it all together and Google may just have a winning hand.

Would you go all-in on Google’s Cloud SQL for Microsoft SQL Server? You can jump in the alpha here. See pricing here.

The post Google’s Cloud SQL for Microsoft SQL Server appeared first on SQL Solutions Group.

You think Demogorgons and Mind Flayers are hard to deal with? Compared to some strange things we’ve seen in SQL Server databases, they’re a walk in the park. 

Most of the time, SQL Server is a wonderful, robust platform that can handle mountains of data, support all sorts of apps, and generally make life easier. Until it doesn’t.

And when it doesn’t, it’s most often because of strange choices made by users:  bad configuration, bad tuning, bad queries, bad monitoring and maintenance, bad all around. And it’s not because the people are bad. Most of the time these are honest, well-intentioned…and strange decisions.

The good news is that we can help you avoid these same mistakes. Over the coming weeks, we’ll outline for you some of the strangest things we’ve ever seen in SQL Server, the negative impact they have, and how you can avoid them and stay out of the Data Driven Upside Down.

Friends don’t lie and we’ll give you the lowdown. So grab your nail-studded bat and join us next week for our first installment … a stored procedure being called seven times a millisecond.  That’s not a typo.  SEVEN times a millisecond,  24×7.  That’s almost 605 MILLION executions per day.  Truth is stranger than fiction.

The post The Strangest Things we’ve seen in SQL Server appeared first on SQL Solutions Group.

In recent weeks, a significant security risk was exposed. This exploit has been named in two fashions: Spectre and Meltdown. We at SSG feel it important to help disclose the severity and impact of these exploits with this formal release.

Email (in**@***************up.com) us now to schedule one of our consultants to help you secure your servers.

The post Spectre and Meltdown Exploits appeared first on SQL Solutions Group.

Changes to Max Memory

In SQL Server 2012, according to this KB Article in the bottom paragraph of the article, after it explains the changes in SQL 2012 for what is included in the governance of max server memory, it explains that in SQL Server 2012 the limitation of the max physical memory is all about Buffer Pool (database cache) and not other things.

In other words, if I have a server with 96 GB of RAM and I put SQL 2012 Standard edition on it, I could set ‘max server memory’ to a number higher than 64 GB and SQL Server would limit Buffer Pool to 64 GB and could use memory higher than 64GB for other things outside the buffer pool. This may not sound like a big deal, but think about wanting more buffer pool but still needing to fit inside the memory limits.

This new allocation allows SQL Server 2012 and higher to use up to the physical limit specified by SQL Server 2012 (Standard = 64GB) and SQL Server 2014 (Standard = 128GB), and to specify a higher number for max server memory than the specified limit of RAM. In this configuration SQL Server will use up to 64GB/128GB for Buffer Pool and memory above that for other parts of SQL Server allocations.

In Enterprise Edition you are limited in RAM only in the limitations of the Operating Systems ability to address that amount of RAM so other editions of SQL Server are the benefactors of this feature.

I would not think of this as a silver bullet, but I think in many cases you can extend the usefulness of the feature if your servers have more RAM than SQL Server can address for the Buffer Pool if you are using Standard and below.

The post When is Max Memory in SQL Server not Max Memory? appeared first on SQL Solutions Group.

Linked Server Review

To start with, lets look at how a linked server works.  We configure a linked server by specifying the remote data source and a name for the sever.

This allows us to use the linked server name ADVENTUREWORKS to access the AdventureWorks database on the instance RKLAPTOPSS.  Note that the Linked Server name can be whatever we want it to.  It does not have to be the name of the instance. I prefer this practice because you can use the same linked server name in multiple environments (Development, QA, Production, etc.)

Authentication settings have to be configured as well.

In this case, I am saying to just pass through the login’s security context to the remote server.  I could also choose to always use a certain security context or to map local login’s to remote logins. The security implications of these choices are beyond the scope of this post but the most important thing is that in most cases Options 2 and 4 should not be used.

With the Remote DBA managed service from

SQL Solutions Group, we do your database dirty

work, freeing up your team for projects

that impact the bottom line.

Learn More

Four Part Naming in Linked Servers

Now that we have a linked server set up, we can access it from the local SQL Server instance.  The most common way to do this is to use four part names to refer to objects on the remote server.

<LinkedServerName>.<DatabaseName>.<Schema>.<Object>

SELECT *
FROM ADVENTUREWORKS.AdventureWorks.HumanResources.Employee
WHERE Gender = 'M'

While this is the most popular way to use Linked Servers, it is also the worst way in terms of performance.  To understand this, you need to always ask the following question: “Where will the query be optimized?”

In this case, the optimizer on the local server will determine the execution plan.  But it doesn’t know anything about indexes and statistics that exist on the Employee table on the remote server.  There may well be an index on Gender which could be taken advantage of, but the local optimizer has no way to know that.   So this query will result in a table scan, every time, regardless of remote indexes. In addition, all of the data will be sent across the network only to be filtered for Gender on the local system.

OPENQUERY()

A better way to do this is to use a function like OPENQUERY().  Essentially what we are doing is executing a remote query on the linked server and just asking for the results back.

SELECT *
FROM OPENQUERY
   (
    ADVENTUREWORKS,
    'SELECT * FROM AdventureWorks.HumanResources.Employee WHERE Gender = ''M'''
   )

The function takes two parameters.  The remote server to execute the query on, and the query itself.  Note that this is remotely executing so if the server was to another DBMS, you’d want the query written in that engine’s flavor of SQL.

This is a simple example, but imagine if the remote table had a million plus rows.  The inefficient table scan plus bringing all that over the network so that it can be filtered locally.  I have “fixed” queries that were taking 12+ hours to run and reduced the time to just minutes by making this simple change to the code.

The post Using Linked Servers the Right Way appeared first on SQL Solutions Group.

I will be doing two sessions at this event:

• Understanding Transaction Isolation Levels
• Understanding SQL Server XML Features

Of course there are many other fantastic sessions as well as a pre-conference session all day on Friday.

Hope to see you there!

The post SQL Saturday #120 – Orange County, CA appeared first on SQL Solutions Group.

My first session was the last one before lunch and is one of my favorites to give.  But it worked in Dev!  SQL Server Performance for Developers is always a lively session with good discussion.  Given that this was a code camp, the audience was almost all developers so it worked out great.  Based on the discussions both during and after the session, I am confident more than a few developers will be looking at their SQL more closely than they did before.  There was one participant who was actually pretty shaken up when learning what “NOLOCK” really does and does not do.  I think I may have ruined his weekend but as they say, forewarned is forearmed.

Thanks to Platinum Sponsor Domo, we had a great lunch catered by Famous Dave’s.  Then it was on to afternoon sessions.  I finished the day participating in a panel discussion of DBA’s called “Ask a DBA”.  This was an informal session with DBA’s representing SQL Server, Oracle, and mySQL.  Most of the attendees were SQL Server users so that is where the discussion seemed to focus but it was great hearing the contrast between the systems anyway.  There were some great questions regarding scalability (up vs. out), NoSQL, and many others. Kudos to Pat Wright for putting this together.

The most impressive thing about this Code Camp was the attendance.  I believe 380 was the offical count and that is almost double what they had last year.  As a sponsor, this was fantastic as we had a ton of people come by the booth and made some good contacts, both as prospective clients and as prospective consultants.  Since the gating factor for the growth of my business has been more in relation to having the consultants to do the work than in having enough work to do, this part is important.

Thanks to the folks at Utah Geek Events who as always, did a fantastic job putting on the event.

The post Utah Code Camp Spring 2012 appeared first on SQL Solutions Group.

Save the Definition

The first thing we need to do is document all the foreign keys so we can re-create them later. I do this by getting the constraint definitions from a couple of DMV’s and storing the pertinent data in a temporary table. Note that if for some reason you lost your connection, you would lose this table so you could give some consideration to using a permanent table.

 1:  SELECT
    2:      fk.name AS FKName
    3:      ,OBJECT_NAME(fk.parent_object_id) AS TableName
    4:      ,OBJECT_NAME(fk.referenced_object_id) AS ReferencesTable
    5:      ,COL_NAME(fk.parent_object_id,fkc.parent_column_id) AS ConstraintColumn
    6:      ,COL_NAME(fk.referenced_object_id,referenced_column_id) AS ReferenceColumn
    7:  INTO #fk
    8:  FROM sys.foreign_keys fk
    9:      INNER JOIN sys.foreign_key_columns fkc ON fk.object_id = fkc.constraint_object_id
   10:  ORDER BY 1

Drop the Constraints

Now we can use dynamic SQL to drop the constraints

  1:  DECLARE 
   2:      @FKName sysname 
   3:      ,@TableName sysname 
   4:      ,@ReferencesTableName sysname 
   5:      ,@ConstraintColumn sysname 
   6:      ,@ReferenceColumn sysname 
   7:      ,@SQL NVARCHAR(4000) 
   8:   
   9:  DECLARE cur CURSOR FOR 
  10:      SELECT FKName, TableName FROM #fk 
  11:  OPEN cur 
  12:  WHILE 1=1 
  13:  BEGIN     
  14:      FETCH NEXT FROM cur INTO @FKName, @TableName 
  15:      IF @@fetch_status !=0 
  16:          BREAK 
  17:   
  18:      SET @SQL = 'alter table ' + @TableName + ' DROP CONSTRAINT ' + @FKName 
  19:      EXEC dbo.sp_executesql @SQL 
  20:  END     
  21:  CLOSE cur 
  22:  DEALLOCATE cur 
  23:  GO

Truncate the Tables

Using the undocumented stored procedure sp_msforeachtabled we can easily truncate all the tables now.

   1:  exec sp_MSforeachtable 'truncate table ?' 

Re-Create the Constraints

Finally, we use dynamic SQL to re-create the constraints

1:  DECLARE 
   2:      @FKName sysname 
   3:      ,@TableName sysname 
   4:      ,@ReferencesTableName sysname 
   5:      ,@ConstraintColumn sysname 
   6:      ,@ReferenceColumn sysname 
   7:      ,@SQL NVARCHAR(4000) 
   8:   
   9:  DECLARE cur CURSOR FOR 
  10:      SELECT * FROM #fk 
  11:  OPEN cur 
  12:  WHILE 1=1 
  13:  BEGIN     
  14:      FETCH NEXT FROM cur INTO @FKName, @TableName, @ReferencesTableName, 
  15:          @ConstraintColumn, @ReferenceColumn 
  16:      IF @@fetch_status !=0 
  17:          BREAK 
  18:   
  19:      SET @SQL = 'alter table ' + @TableName + ' ADD CONSTRAINT ' + @FKName + 
  20:          ' FOREIGN KEY(' + @ConstraintColumn + ') REFERENCES ' 
  21:          + @ReferencesTableName + '(' + @ReferenceColumn + ')' 
  22:      EXEC dbo.sp_executesql @SQL 
  23:  END     
  24:  CLOSE cur 
  25:  DEALLOCATE cur 
  26:  GO

Finally a quick script to check the final row counts

 1:  create table #rowcount (tablename varchar(128), rowcnt int) 
   2:   
   3:  exec sp_MSforeachtable 'insert into #rowcount select ''?'', count(*) from ?' 
   4:   
   5:  select * from #rowcount order by tablename 
   6:   
   7:  DROP TABLE #rowcount 
   8:   

The post Truncate Tables that have Foreign Keys appeared first on SQL Solutions Group.

The post Utah Code Camp appeared first on SQL Solutions Group.