07/03/2014
by Marlon Ribunal
0 comments

Executing scripts on multiple servers the easy way

Central Management Server and server groups provide a convenient way to manage multiple servers and databases in one place and at the same time.You can register and manage any servers but only those in SQL Server versions 2008 and higher can be designated as Central Management Server. You can execute TSQL scripts on any or all the servers registered under the Central Management Server at the same time. If you have a Policy-Based Management structure in place, the Central Management Server makes it easy to execute policies on multiple servers at once. I’ve said that enough – at the same time. Click once, and you’re done with all the servers.

But what if, for some reasons, you cannot use Central Management in your environment?

This is the reason why tools like SQL Multi Script from Red Gate Software exist. Some of the features I like are:

  • Set the execution order of multiple scripts
  • Query databases in parallel
  • Messages from SQL Server displayed for all databases
  • Execute just the selected text in a script (just like in SSMS)

Let’s take a look. For this demo, we’re using two SQL Server 2012 instances from two separate servers on a domain. This demonstrates that we can use the SQL Multi Script tool on multiple servers across a network.

The first time you run the tool, you need to build your Database Distribution List:

1. Click the Configure button Build Database Distribution List 2. On the Configure Database Distribution List Dialog, click the New button. Type in a name for the new distribution list, then click Create. Let’s put SQL2012_Dev_Servers for this demo. This list is for databases, but I’d still like that “servers” in the nomenclature to have that logical grouping by servers. Using distribution lists is a good way of having that separation among server groups; e.g., Test, Dev, QA, Production, etc. So name your lists as intuitive as possible. Creating New Distribution List in SQL Multi Script 3. Still on the Configure Database Distribution List Dialog, click the Add a SQL Server Not Listed button. Type in the SQL Server whose databases you want to add to the distribution list, specify your authentication credentials, then click Add. Remember the distribution list is for databases, not for servers. Repeat this step for all the servers you want to add. Add SQL Server to Multi Script Distribution List 4. Now that we have added the servers, let’s add the databases we want to list in our SQL2012_Dev_Servers distribution list. Select the databases you want to add in the distribution list. You can multi-select databases among the servers by pressing CTRL + Right Click key. Then, click the Add button. Select database to add to the multi script distribution list 5. You can now see the databases in the Databases to Execute Against pane under the Distribution list. Click OK. Add database to databases to execute against in SQL Multi Script 6. You can create a new script via the SQL Multi Script editor; and, save that script for later use. You can also add an existing script. For this demo, let’s do the latter. Click the Add button. Select the script you want to add from the Add File Dialog box. I’m adding two scripts for this demo: a script that creates a database called DBTools and sp_Blitz by Brent Ozar Unlimited. I don’t intend to violate the sp_Blitz trademark here. I just want to demo that an enterprise-ready script such as sp_Blitz can execute in SQL Script.

add existing scripts to SQL Multi Script

 7. Like I mentioned in the beginning of this post, one of the features that I really like in SQL Multi Script is the ability to set the execution order of multiple scripts. The first script, Create_Database_DBTools.sql, creates a database called DBTools. The second script, the sp_Blitz (Brent Ozar Unlimited trademark), creates the sp_blitz stored procedure on the DBTools. Let’s order the two scripts so that the Create_Database_DBTools runs first before the sp_blitz script; otherwise, it will throw a missing object error. I modified the sp_blitz to run on the DBTools database instead of the default database (master).

Let’s parse the script to make sure our scripts are error-free. In this demo, I’m getting a “DBTools database does not exist” error, which makes sense, because the DBTools database has not been created at this point.

One of the features of SQL Multi Script is its ability to display Messages from SQL Server, which exactly is what we see here:

SQL Server message displayed on SQL Multi Script

8. If you’re executing long and complicated scripts, encountering errors is a possibility. SQL Multi Script provides a list of actions to be taken when an error occur; i.e., Continue Executing, Skip script on database with error, Stop executing on database with error, and Stop executing.

On error action when script has error on SQL Multi script

 

9. Let’s execute our scripts. We should get a confirmation that the scripts ran successfully. The tools did not encounter an error this time because we executed the two scripts in the correct order.

Script run successfully confirmation on SQL Multi Script

10. Let’s check our databases through SSMS, and make sure that the objects we just created through SQL Multi Scripts exist. The following screen captures show that the DBTools database and sp_blitz stored procedure objects are indeed created on both the SQL2012-A and SQL2012-B servers.

objects created by SQL Multi Script

database objects created by SQL multi Script

11. But here’s more. Here’s another feature I like in the tool – it’s ability to display the results of the script. Let’s execute the sp_Blitz via the SQL Multi Script tool. But before we do that, let’s add the DBTools from both SQL2012-A and SQL2012-B to our SQL2012_Dev_Servers distribution list. This time, instead of adding an existing script, let’s create a new script in the editor:


EXEC [DBTools].[dbo].[sp_Blitz]
@CheckUserDatabaseObjects = 1 ,
@CheckProcedureCache = 0 ,
@OutputType = 'TABLE' ,
@OutputProcedureCache = 0 ,
@CheckProcedureCacheFilter = NULL,
@CheckServerInfo = 1

Let’s execute that TSQL. SQL Multi Script should be able to show us the results of the sp_Blitz stored procedure, like this:

SQL Multi Script Query Results

The SQL Multi Script is a neat tool. I recommend it if you’re looking for something like this.

01/09/2014
by Marlon Ribunal
3 Comments

Laying The Ground For A Successful Reporting Project

Building a reporting system from the ground up is a daunting task. Such a big project usually involves intricate resource movement. Reporting is an important component of Business Intelligence (BI). Therefore, perceptive implementation options of the reporting portion should be considered. Data analysis and integration become pointless if they lack the proper delivery of meaningful presentation to those who need them.

Purposeful research and requirement analysis precede any action in the initial or implementation phase of the project. But more crucial than understanding the requirements is possessing a deep knowledge not only of the business processes but also of the company itself.

Laying the ground for the success of your reporting project reckons on few factors that are within your control:

Immerse yourself in the business

Knowing what your company does gives you a leverage in any reporting initiative. You must know your company from the inside out – the products or services, the customers, the target market, the competitors, the industry, the stakeholders, among others.

It is not enough to know all the processes or procedures in conducting the business of your company. The key here is to get yourself as close to the core of the business as possible. Make it personal. Feel your company’s heartbeat. Develop a genuine concern for the company.

Immersing yourself in the core of the business gets you to a level where you are comfortable in dealing with every situation that arises in the midst of the project. Plus, it will align all the values you uphold to that of the company. Why is this important? Seeing things with the same lens that the company is seeing through is an indispensable step in understanding the vision of the company.

Understand the desired metrics

What are you trying to measure? Knowing the vision of your company helps you to identify the key barometers and parameters. The Key Performance Indicators give a good glimpse of how far or near the company is to its goals or objectives.

The key is to identify the indicators that bespeak of what the company is trying to achieve. It is one thing to have the cutest dashboard, it is another thing to have a meaningful dashboard. We tend to get enamored of the latest and shinest dashboard tools. Just because you can build the most complicated dashboard doesn’t mean you should. Ask yourself this question before you build: Does this hold meaning to what my company wants to measure?

Get to know your report consumers

If you are in the same mindset as the late Steve Jobs, you have an inkling of how often your report consumers do not know what they want to see in their reports. I experienced this myself in the past. I received this specs and built the report based on them. The next morning I received a complaint from the person who requested for that report. I followed his specs to a tee.

That is the common mistake of report developers – accepting requirements or specs without taking into consideration the user’s perspective. Steve Jobs is often correct in this regard. Hence, knowing the business processes and understanding the company metrics is very important.

Understand what your users want. See what they have on those Excel sheets sitting on their laptops. Understand how data influence their day-to-day decisions.

Live and breathe data

As a data pro, you must live and breathe data. One part of the equation in any report project is the metadata – the intangibles or the business processes; the other part, which is equally important, is the data themselves. The data hold every meaning your company wants to draw from their business.

Understand collation, data types, indexes, performance, etc. Learn the structure of your data as they are stored in your databases. Understand how they are collected and to which application they are tied with.

Getting the upper hand on every business application deployed in your company is half the battle.

To sum up, there are few things to consider before you even deal with a reporting project head on. It is not enough that you understand the project specs. Knowing what’s behind every process and number play an important role in the success of your reporting project.

10/29/2013
by Marlon Ribunal
10 Comments

My First Book: SQL Server 2012 Reporting Services Blueprints

Packt Publishing has published SQL Server 2012 Reporting Services Blueprints – the book that Mickey Stuewe (b | t) and I have been collaborating on for months. Packt has published this title under their Blueprints Series.

What exactly is a Packt Blueprints Book?

“Blueprints are basically in a standard tutorial format, […] Continue Reading…