1. Toad for SQL Server – Pro Edition – $650 /user
2. DB Visualizer Pro – $176 per user
3. dbForge  – $99 / per user / year
4. Navicat for SQL Server (Windows) Standard Edition – $459 per user (one time)
5. Eclipse Data Tools Platform  – Free with Eclipse; learning curve required

The post SQL Visual Query Construction tools appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

SQL Server provides database-level redundancy through:

1. backup/restore
2. log shipping
3. database mirroring (in SQL Server 2005 and later)
4. Always on Clustering (SQL 2012 onwards)

Mirroring means master-master replication which leads to concurrency/transaction issues. Database mirroring may be the only mechanism for a real-time copy of the database with zero RPO (zero Recovery Point Objective = zero data loss); however, it is error-prone and costly.

The reason replication is preferable is because in every DB, you need to distinguish between reads and writes.  Reads are directed to slave(s), whereas writes always go to master.Even in master-master scenarios, sending WRITE queries to different servers is dangerous and error-prone.

WFSC as part of SQL Always-On Clustering

As part of the SQL Server Always On offering, Always On Failover Cluster Instances leverages Windows Server Failover Clustering (WSFC) functionality to provide local high availability through redundancy at the server-instance level—a failover cluster instance (FCI). An FCI is a single instance of SQL Server that is installed across Windows Server Failover Clustering (WSFC) nodes and, possibly, across multiple subnets. On the network, an FCI appears to be an instance of SQL Server running on a single computer, but the FCI provides failover from one WSFC node to another if the current node becomes unavailable.

DR versus Failover

Failover of Web and App Tiers

Windows offers a WSFC – Windows Server Failover Cluster which can be used to provide true failover (think multiple nodes). App and Web Servers – Possible to failover automatically provided the multiple app/web servers are part of a WFSC.

DR of Web and App Tier

DR can also be achieved through WFSC –  however, in practice, it might be simpler to simply have a copy of the app running on the Failover Node. This way, the entire application can ‘recover’ – one simply points users to the copy of the app running in the redundant data center.

Failover of Data Tier

Using Always On Clustering, failover of a database itself is simplified. All the database objects will automatically failover to the Secondary Always-On Node (could be in your backup datacenter). However, users, roles and even some StoredProcs, will not carry over – and will need to be manually recreated.

DR of data tier

For true DR, live replication may be needed. This is possible with and without Always On.

Summary

For data recovery, in theory, mirroring works best. However, in practice, replication usually wins over mirroring. This is because a typical app has both – READs and WRITEs.

When architecting a full n-Tier app DR scenario, one needs to deal with each  tier separately – as the technologies involved may differ. For Web and App Servers, WFSC or even manually recovering are both possible( Again, In theory WFSC wins, in practice, manual recovery is preferred).  

The post Mirroring, Replication and Always On Clusters appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

The post SQL Server Geo Replication appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Sometimes, web tiers will be designed to do more than just CRUD operations. For e.g. – a web app that creates database tables on the fly – would need a DDLAdmin level privilege.

Web Tiers of such applications need an almost full-blown db_owner privilege on their own database. The common response is – okay – since all you can do is damage to just your own database – not other databases on the instance. Turns out, that is far from true. A db_owner on any ONE database – can still bring down the entire server – and do other nefarious things.

What damage can a SQL Server db_owner do?

db_owner can write a trigger that can elevate her own priviliges to sysadmin

Db_Owner can alter the data file size – and fill up the entire diskspace.

–===============
–db_owner HACKER can CHANGE The data file sizes
–===============
ALTER DATABASE [mydatabase] MODIFY FILE
(
                NAME = N’mydatabase’
, SIZE = 3000MB
, FILEGROWTH = 512MB
)
ALTER DATABASE [mydatabase] MODIFY FILE
(
                NAME = N’mydatabase’_log’
, SIZE = 2000MB
, FILEGROWTH = 512MB
)
GO

Db_owner can keep creating new logins, ad infinitum – and fill up all available memory.

USE [master]
GO
CREATE LOGIN [foo] WITH PASSWORD=N’Some_really_difficult_pa$$word’
, DEFAULT_DATABASE=[iDBA]
, CHECK_EXPIRATION=OFF
, CHECK_POLICY=ON
GO
USE [iDBA]
GO
CREATE USER [foo] FOR LOGIN [foo]
ALTER ROLE [db_owner] ADD MEMBER [foo]
GO

The post db_owner security risks appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

The post Accessibility – 508 Compliance and SSRS reports appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

1. Lowers overall cost of ownership by providing a single platform to collapse databases onto.
2. Provides out of the box High Availability – and (automatic) Scalability options.

SQL Server has been trying to play catch up for a while. With the release of their AlwaysOn SQL Server cluster feature, they are starting to come close. This post examines implementing a SQL Server RAC like structure on AWS (which offers a few additional optimizations).

Collapsing SQL Server

AWS Specific SQL Collapse – Some advantages of AWS

• EBS Optimized Instances – I/O optimized
• Enhanced Networking on windows.
• AWS Placement Groups – logical grouping of instances within a single Availability Zone. Placement groups are recommended for applications that benefit from low network latency, high network throughput, or both. 

SQL Always-On High Availability Group

Highlights

1. Each set of availability databases is part of an availability replica. These come in two flavors : a single primary replica. which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set of secondary databases. The secondary dbs can serve as potential failover targets.
2. An availability group fails over at the level of an availability replica. An availability replica provides redundancy only at the database level—for the set of databases in one availability group.
3. Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file or corruption of a transaction log.
4. Relies on underlying Windows Clustering.  AlwaysOn Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster. Each availability replica of a given availability group must reside on a different node of the same WSFC cluster.

SQL Always-On in AWS

AWS Whitepaper

Highlights

1. You must deploy the cluster nodes inside an Amazon VPC.
2. You must deploy WSFC cluster nodes in separate subnets. Keeping these two key requirements in mind, we provide instructions for deploying the WSFC and an AlwaysOn Availability Group.
3. We call out any AWS-specific considerations along the way. First, we provide implementation guidance for setting up AD DS in an Amazon VPC. Next, we walk you through the steps necessary to configure a two-node automatic failover cluster with a file share witness.
4. On this cluster, we then deploy an AlwaysOn Availability Group with two availability replicas.
5. The goal of this configuration is to protect from the failure of a single instance. Other failover cluster and availability group configurations are possible to serve either high availability (HA) or disaster recovery (DR), or both scenarios together.

The post Creating an Oracle RAC like structure with SQL Server Technology appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Here are a few things that you will get with SQL Enterprise that you will not with SQL Standard

Vertical Scalability

Can use the maximum amount of RAM and number of core processors that the host system offers.

Superior DBMS capabilities scalability features as table and index partitioning, data compression and partition table parallelism.

Horizontal Scalability and High Availability

High Availability is also superior in Enterprise Edition. Creating database snapshots, multisubnet clusters and mirrored backups are all part of Enterprise Edition.

Always On Availability Groups

While Microsoft is planning to offer these for Standard Edition as well (from 2016 onwards), AlwaysOn availability groups were a MAJOR Enterprise feature that provided configurable SQL Clusters (think of an Oracle RAC like structure with multiple redundant nodes).

Data Security – TDE

Transparent data encryption (TDE) is a feature built into SQL Enterprise. It is faster and more efficient than doing an entire DISK encryption (which is your only option with SQL Server).

The Cost Difference – SQL Enterprise vs. Standard

Enterprise SQL Server is typically about 3.5 times as expensive  as the standard.

Standard = $2000 per core

Enterprise = $7000 per core

Summary

While Enterprise edition hurts your pocket more, if  Scalability and Security are a real concern for your application ( s) , consider SQL Enterprise.  It is the only thing that comes truly close to an Oracle RAC – with it’s high availability and lightning fast performance features.

The post When to consider SQL Server Enterprise appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

If you are concerened with High Availability – and less with multi-tenant hosting, SQL Server Always On Availability Groups (AoAG) come close to the availability and scalability of RAC.  

One can scale out reads by querying against the mirrors, but  all DML needs to be directed at the primary server (SQL Server mirrors are read only and not updateable). If the primary SQL Server crashes, failover to one of the mirrors is near instantaneous. RAC experiences a similar pause if a node crashes as uncommitted transactions on the failed node are rolled back.

Load balancing through Replication – The only direct relation between replication and load balancing is that you need some replication to be able to load balance, else you’d have a single server.

The post Oracle RAC equivalent for SQL Server? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

 If you are interested in having a large SHARED memory pool that can host multiple tenants (multiple apps), then SQL Server Enterprise can provide you with that memory pool. The maximum memory for SQL Server Enterprise is the OS max – which is 4TB for a Server 2012 OS. For SQL Server Standard, the max limit is 128 GB – which may still be enough to provide a multi-tenant environment.

If you are concerened with High Availability – and less with multi-tenant hosting, SQL Server Always On Availability Groups (AoAG) come close to the availability and scalability of RAC.  

One can scale out reads by querying against the mirrors, but  all DML needs to be directed at the primary server (SQL Server mirrors are read only and not updateable). If the primary SQL Server crashes, failover to one of the mirrors is near instantaneous. RAC experiences a similar pause if a node crashes as uncommitted transactions on the failed node are rolled back.

Load balancing through Replication – The only direct relation between replication and load balancing is that you need some replication to be able to load balance, else you’d have a single server.

The post Oracle RAC equivalent for SQL Server? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Multi-tenant SQL Server Environment (Collapsed Environment)

If you are interested in having a large SHARED memory pool that can host multiple tenants (multiple apps), then SQL Server Enterprise can provide you with that memory pool. The maximum memory for SQL Server Enterprise is the OS max – which is 4TB for a Server 2012 OS. For SQL Server Standard, the max limit is 128 GB – which may still be enough to provide a multi-tenant environment. 

Collapse Strategies

One can collapse by simply stacking all databases onto one instance (Database stacking), by installing separate instances for each database (instance stacking) or by providing VMs for each instance (VM based collapse strategy)

High Availability

If you are concerened with High Availability – and less with multi-tenant hosting, SQL Server Always On Availability Groups (AoAG) come close to the availability and scalability of RAC.  

One can scale out reads by querying against the mirrors, but  all DML needs to be directed at the primary server (SQL Server mirrors are read only and not updateable). If the primary SQL Server crashes, failover to one of the mirrors is near instantaneous. RAC experiences a similar pause if a node crashes as uncommitted transactions on the failed node are rolled back.

Load balancing versus Replication

The only direct relation between replication and load balancing is that you need some replication to be able to load balance, else you’d have a single server.

The post Oracle RAC equivalent for SQL Server? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.