look around

This week, we'll take a look at part 4 of our series on application high availability and disaster recovery (HA/DR) for SQL Server: replication.

Part 1: Application High Availability and Disaster Recovery for SQL Server
Part 2: Poor Man's Disaster Recovery: Use Log Shipping for SQL Server (at Your Own Risk)
Part 3: Database, Database on My Server, Do I Mirror Thee, Sync, or Async?!

SQL replication is a publication-subscription model. The publishers (source servers) define the data or database objects (i.e., articles/publications) to publish and the subscribers (target servers) decide any or all data (i.e., subscriptions) to receive.

SQL Server supports three types of replications:

Snapshot – generated and applied immediately after a subscription is created, or according to a schedule set at the time the publication is created.Transactional – committed transactions made at the publisher can be distributed and applied immediately at the subscriber or at scheduled intervals. Near real-time data availability can be achieved.Merge – bi-directional replication where incremental updates at both subscriber and publisher are synchronized and merged.

To configure replications, you can use the following references:

Selecting the Appropriate Type of ReplicationDesigning and Implementing: Walkthroughs (Replication)

There are many advantages and disadvantages with using replication compared to other HA/DR solutions. Let's take a closer look at some considerations:

Depending on your appetite. You decide what database objects to publish and subscribe. The dataset (i.e., article) can be as small as a single row in a table or as big as all the tables, views, stored procedures, user functions, etc. in the database.Whenever you want. You decide when the data should be published and applied to the target servers. For near real-time replicated data, you can use transactional replication to push out the changes to target servers. If it's one way replicated data, you can periodically do a snapshot of the data and push it to the target servers.Push or pull. Unlike other HA/DR solutions, replication can be configured to either push or pull changes from the publisher to subscribers. A pull topology is best when bandwidth is limited and you have a fixed maintenance window. You only pull changes on a per-need basis.Big fan (subscriber) base. You can have as many as subscribers as you'd like. As long as your network bandwidth is capable of handling reasonable data transfer rates between the servers, you can have yourself all the fans in the enterprise.No automatic failover. There is no coordination for an automatic failover or failback. Each server in the replication model is an independent server with its own set of users. If you use merge replication or transactional replication with updating subscriptions then the replicated data can be made consistent across all servers. It is still a manual process to switch the connection between servers.Data loss or corruption. Depending on when the changes are replicated or synchronized on the servers, data loss can occur. Also, there is no protection for the replicated data. Every change made at the publisher is logged in the form of a DDL or DML command in the distribution database, to be delivered to the subscribers. If proper rules and filters are not in place, you could certainly corrupt your data on the subscribers (i.e., invalid updates, inserts, or deletes).Real-time, really. Replication is never really real-time. The Log Reader Agent monitors the transaction log for the articles defined for your publication, and when it finds changes it translates them into appropriate insert, update, delete commands and logs them in the distribution database. These commands are then applied at the subscribers to make the data consistent. There is a cost in this lookup, command translation, and delivery; thus, replication is never real-time.Bloated distributor. Old commands logged in the distribution database can bloat the distributor. You should consider setting rules to clean up these old commands. It is really a challenge to keep the distributor lean and mean.Publishers and subscribers can be any HW/SW class. The servers are completely independent of each other and do not need to be hosting the same applications, even if they share the same replicated data. The publisher and subscriber can even be running different database software. For example, a SQL Server publisher and Oracle subscriber (or vice versa).Servers can be anywhere. Your mileage varies depending on the amount of data to be replicated. As with any OLTP system, WAN or latency always has major impact on performance. You may consider creating and publishing many small publications instead of some large ones.

Replication is probably one of the most flexible HA/DR solutions in term of defining and synchronizing data between servers. You can basically decide what to publish and what to subscribe to. Any objects within a database system (SQL Server, Oracle, DB2, etc.) is fair game for replication. But without the built-in page fault recovery, conflict resolution rules and policies, and automatic failover, you have to take extra special care to ensure data validity and consistency across your systems. Also, if you need protection at the instance or server level, replication is not the answer and you will have to check out other HA/DR solutions.

I hope you find the replication information above useful and will join me again in the next installment of the Application High Availability and Disaster Recovery (HA/DR) for SQL Server series, where I will discuss another HA/DR solution.

Do you have a specific question about HA/DR solutions? If so, please let me know and I'll try to provide insight and solutions. Cheers!

View the original article here

Server shipments grew marginally in the second quarter of 2014 – the first rise in nearly three years. Gartner’s server report for Europe, the Middle East and Africa (EMEA) showed 0.8% growth in shipments for the quarter following falls in the 11 previous quarters.

Server revenue also grew for the second consecutive quarter of 2014 to touch $3.2bn, a 3.8% year-on-year increase after 10 consecutive quarters of revenue decline.

“The second quarter of 2014 marks a key milestone in the server market for many suppliers, as both shipments and revenue grew for the first time since this period in 2011,” said Errol Rasit, research director at Gartner.

But he warned: “Despite the steady improvement in the server market, these positive results highlight the end of a slump, rather than a return to growth. Server providers must continue to ensure that a focus on growth remains a top priority.”

Among the server suppliers, HP led the pack with 7.3% year-on-year growth to achieve a 34.7% server revenue share for Q2 2014.

IBM recorded the second-highest market share, but saw its server revenue shrink by 14.9% for the second quarter of 2014. All other server suppliers, including Dell, Oracle and Fujitsu, saw their server revenues rise in the second quarter.

Third-placed Dell’s recent momentum continued, with its revenue for the quarter up 13.5% and its shipments up 5.5%.

HP’s 7.3% growth is a strong result given its shipment decline of 5.2%, said Gartner. Although the EMEA market does not enjoy the same hyper-scale demand as North America, HP was able to benefit from strong multi-node server sales to boost its growth, the analyst added.

Second-ranked IBM recorded single-digit x86 growth, despite announcing the divestment of this business, but the company’s top-level result was hit by a cyclical low point in mainframe sales and ongoing weakness in its RISC systems business, said Rasit.

“Despite top- line positivity, mixed supplier and regional results during the second quarter highlight the ongoing challenges the server market faces in EMEA,” he added. “Demand is positive, but server customers are increasingly discerning regarding technology choice and cost. These two opposing factors could limit server market growth in 2014, although we expect continued improvement in the second half of the year.”

From a regional perspective, only Eastern Europe saw revenue and shipment declines, of 1.6% and 5.6% respectively. Server revenue and shipments in the Middle East and Africa region grew by 2.5% and 6%, respectively, while Western Europe saw revenue rise by 4.8% and shipments by 1.3%.

In the second quarter of 2014, x86 server revenue increased by 12.7% in EMEA, RISC/Itanium Unix revenue declined 23.6% and “other CPU” revenue fell by 17.8%, Gartner reported.

“It is not surprising to see the x86 segment driving growth in EMEA,” said Rasit. “However, double-digit declines in the RISC and Itanium Unix segments were weaker than expected, highlighting ongoing instability.”

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy$("a#eproductLogin").attr('href', function(i) { return $(this).attr('href') + '?fromURL=' + regFromUrl; });

View the original article here