casinos

Archive for the ‘Technology’ Category

Use existing connections in PowerPivot and Visual Studio April 1st, 2014

Vinod Kumar

I have been fortunate enough to work with a lot of data which involve using of PowerPivot or customers using Tabular model using BISM. Though there are striking similarities in building both the tasks, the mistakes made in both these models are almost the same. Let me talk you through this for a moment.

Whenever we work with PowerPivot or BISM model and we are importing data from a data source, the initial tendency is to use the “From Database” or “From Other Sources” tab and we start building the model. This is a fair step and in doing a data mashup, we bring data from multiple sources.

Many a times we might connect to the same data source using the above step. And to our irony we will encounter the following in our existing connections. In the example below, I have made 3 different query to the same data source and it is now pointing to the same source – 3 times. Isn’t it inefficient? I have seen customers having close to 20-25 connections to the same source but they are bringing some 20-25 different tables. I have observed the performance during “refresh” gets severely hampered by this approach.

So how to get around this? The steps are simple. Whenever you want to connect to the same source – click on the “Existing Connections” button.

Select the source that you want to reuse as a connection. And now select “Open”.

We will be presented with the same wizard as we normally do with “New Connection” Wizard.

The steps are similar when using the same in Visual Studio too when developing BISM models.

Continue reading...


 

SQL Server 2014: New function sys.fn_hadr_is_primary_replica March 25th, 2014

Vinod Kumar

My latest explorations have been to look at what are the fine print details that got added with SQL Server 2014. Especially, I have been exploring what has fundamentally changed when it comes to SQL Server 2014 – AlwaysOn capabilities. Though at the outset this looks simple and basic, some of these enhancements are pretty cool and needs a mention. Hence you are getting these bunch of blogposts inspired by this learning.

In SQL Server 2012, we had this neat little function – sys.fn_hadr_backup_is_preferred_replica which allowed us to be used during the backup operation if the replica we are running backup against is the preferred replica as per the AlwaysOn configuration. Though it was a neat addition there was no way to figure out if the node on which the Maintenance plan was running was ever the Primary replica. To illustrate the enhancement, I am having the following configuration as shown in the figure below.

As you can see I have two servers SQLALWAYSON01 and SQLALWAYSON02 servers and the -01 server is the PRIMARY. With SQL Server 2014, there is a new function that gets introduced – sys.fn_hadr_is_primary_replica. This nifty function when passed with the database name will return 1 if it is run on the PRIMARY. Else it will return you 0, if invoked from the secondary replicas.

In my opinion this is a critical and nifty option because you might want to do certain operations ONLY on the Primary like index rebuilding, full backups or whatever. Apart from these values, if you by any chance pass a non-AG database to the function it will return you NULL as shown in the figure below. Do let me know if you will use this function and what are the scenario’s you will find this useful. It can surely be a great learning for me too to listen from you.

This post is inspired from Book content: SQL Server 2012 AlwaysOn Joes 2 Pros®: A Tutorial for Implementing High Availability and Disaster Recovery using AlwaysOn Availability Groups” (Paperback, Kindle).

Continue reading...


 

SQL Server AlwaysOn–SQL 2014 Readable Secondary changes March 20th, 2014

Vinod Kumar

This is in continuation to the post around SQL Server AlwaysOn-Readable Secondary Setting which I posted earlier. With every new release there are multiple enhancements and I know by the time we published our book on AlwaysOn many of these features were not quite available and we missed writing about them.

One of the main addition with SQL Server 2014 for AlwaysOn is the capability to have 8 secondary replica. This is has been discussed exclusively in the book and the number of synchronous nodes etc remain as in SQL Server 2012. Nothing much changes. It is important to understand that commits don’t wait for async replica’s hardening, so there will be not much of an impact wrt to deployments are concerned.

Enhanced Readable Secondary with SQL Server 2014

So what are the new scenario’s that we are talking about from a readability point of view? In SQL Server 2012, when the availability on the secondary databases was either NOT SYNCHRONIZED (Data movement SUSPENDED) or in RESOLVING state we were not able to connect to the secondary node for ReadOnly workloads.

Scenario 1: In SQL Server 2012 if we take the Availability group to Offline mode, the secondary databases get into a RESOLVING state and we get the following error:

Unable to access database ‘AdventureWorks2012′ because its replica role is RESOLVING which does not allow connections. Try the operation again later. (Microsoft SQL Server, Error: 983)

From SQL Server 2014, existing connections made to the secondary replica directly can still be served and new connections will also be allowed.

Scenario 2: In SQL Server 2012, if data movement gets suspended, the availability database gets into a NOT SYNCHRONIZED state. In such scenarios the connections are refused and we get the following error:

The target database, ‘AdventureWorks2012′, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.

Or we might get a read access error on the secondary. Either way, with SQL Server 2014, this is no longer a problem as read directly to the secondary is possible even when the synchronization is suspended.

Note: Irrespective of the scenario mentioned above, the read operation cannot be performed using the Listener and routing list. In either of the case of RESOLVING or NOT SYNCHRONIZED state if you use the Availability Group Listener name/IP we will get the below error.

Unable to access the ‘AdventureWorks2012′ database because no online secondary replicas are enabled for read-only access. Check the availability group configuration to verify that at least one secondary replica is configured for read-only access. Wait for an enabled replica to come online, and retry your read-only operation.

Thought this is a critical hidden enhancement with AlwaysOn, it can surely come in handy for Hybrid scenarios, or when quorum is lost scenarios where we still get the ability to read from our secondary directly as a last resort and worst case operation.

This post is inspired from Book content: SQL Server 2012 AlwaysOn Joes 2 Pros®: A Tutorial for Implementing High Availability and Disaster Recovery using AlwaysOn Availability Groups” (Paperback, Kindle).

Continue reading...


 

SQL Server 2014: Backup Informational messages March 17th, 2014

Vinod Kumar

This is in continuation to the previous observation I had with backups in SQL Server 2014. Backups are such a mundane every task for a DBA that there hardly much to talk about. Infact in a lot of sessions I ask how many can take a backup in SQL Server, I get about all of them are so confident in using the same with few clicks via SSMS.

So with something as trivial as backup what can some of the message enhancement be? Interestingly, if you have ever taken a backup in the past you will see a number of informational messages. Some of these messages like the one below were always sent to the Errorlogs of SQL Server for records.

If you ever take a backup using T-SQL commands there is another interesting message that gets displayed which is lost after you close the results tab.

With SQL Server 2014, I found the above message being sent to the errorlogs and it is quite an handy information one can have. A typical message now sent would be:

BACKUP DATABASE successfully processed 298 pages in 0.026 seconds (89.261 MB/sec).

If that was not enough, I did a normal restore of the database and Woot !!! We get a similar message on the time it took to actually restore operation.

RESTORE DATABASE successfully processed 298 pages in 0.016 seconds (145.050 MB/sec).

I have personally felt the SQL Server Error Logs are a Pandora of information of your system health. It has amazing wealth of information that sometimes when you troubleshoot ticket for your SQL Server environments our support team generally also asks you to provide the Errorlogs as part of their dumps. With so much interesting information added, these enhancements are hardly noticed by DBA sometime.

PS: Click on the images to get a hi-res readable copy.

Continue reading...


 

SQL Server 2014: Checksum with backups March 14th, 2014

Vinod Kumar

At the MTC, I have been a big time supporter of using CHECKSUM’s in your Page_Verification setting as a best practices. Some of these technology innovations that we do are hidden deep somewhere in-between the options that we don’t get to see. Inorder to get the best of your SQL Server and detect IO related potential issues, it is highly recommended to turn this setting ON.

Now, we also recommend using the CHECKSUM verification with backups. Many a times have seen customers actually have their own third party solutions to take backups and many times this option is never being used. The consequence of this is, a bad backup yields a bad corrupt restore too. So I highly recommend you read this KB article for prior to SQL 2014 deployments.

What is new with SQL 2014?

From SQL Server 2014 onwards we introduce a capability of enabling checksum at the server level by default irrespective of the backup tool that you use. This is an nifty and handy setting and I will be recommending my customers to use this by default.

The image above shows the setting available by default. So to enable the same use the following command.

sp_configure ‘backup checksum default’, 1

GO

RECONFIGURE

As I sign off this new learning, wanted to check how many of you use the CHECKSUM feature as described at the database level atleast? I am getting into this small learning experiences working with SQL Server 2014 for a while and I will keep posting them in future blogs too.

Continue reading...