(Download PDF) Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter PDF

Azure SQL Hyperscale Revealed:
High-performance Scalable Solutions

for Critical Data Workloads 1st Edition
Zoran Bara■
Visit to download the full and correct content document:
https://ebookmass.com/product/azure-sql-hyperscale-revealed-high-performance-scal
able-solutions-for-critical-data-workloads-1st-edition-zoran-barac/
More products digital (pdf, epub, mobi) instant
download maybe you interests ...
Azure SQL Hyperscale Revealed: High-performance

Scalable Solutions for Critical Data Workloads 1st
Edition Zoran Bara■
https://ebookmass.com/product/azure-sql-hyperscale-revealed-high-
performance-scalable-solutions-for-critical-data-workloads-1st-
edition-zoran-barac/
Developing Cloud-Native Solutions with Microsoft Azure

and .NET: Build Highly Scalable Solutions for the
Enterprise 1st Edition Ashirwad Satapathi
https://ebookmass.com/product/developing-cloud-native-solutions-
with-microsoft-azure-and-net-build-highly-scalable-solutions-for-
the-enterprise-1st-edition-ashirwad-satapathi/
Modern Data Architecture on Azure: Design Data-centric

Solutions on Microsoft Azure 1st Edition Sagar Lad
https://ebookmass.com/product/modern-data-architecture-on-azure-
design-data-centric-solutions-on-microsoft-azure-1st-edition-
sagar-lad/
Practical Graph Structures in SQL Server and Azure SQL:

Enabling Deeper Insights Using Highly Connected Data
1st Edition Louis Davidson
https://ebookmass.com/product/practical-graph-structures-in-sql-
server-and-azure-sql-enabling-deeper-insights-using-highly-
connected-data-1st-edition-louis-davidson-2/
Practical Graph Structures in SQL Server and Azure SQL:
Enabling Deeper Insights Using Highly Connected Data
1st Edition Louis Davidson
https://ebookmass.com/product/practical-graph-structures-in-sql-
server-and-azure-sql-enabling-deeper-insights-using-highly-
connected-data-1st-edition-louis-davidson/
Pro SQL Server 2022 Wait Statistics: A Practical Guide

to Analyzing Performance in SQL Server and Azure SQL
Database, 3rd Edition Thomas Larock
https://ebookmass.com/product/pro-sql-server-2022-wait-
statistics-a-practical-guide-to-analyzing-performance-in-sql-
server-and-azure-sql-database-3rd-edition-thomas-larock/
Pro SQL Server 2022 Wait Statistics: A Practical Guide

to Analyzing Performance in SQL Server and Azure SQL
Database, 3rd Edition Thomas Larock
https://ebookmass.com/product/pro-sql-server-2022-wait-
statistics-a-practical-guide-to-analyzing-performance-in-sql-
server-and-azure-sql-database-3rd-edition-thomas-larock-2/
Beginning Azure Functions: Building Scalable and

Serverless Apps 2nd Edition Rahul Sawhney
https://ebookmass.com/product/beginning-azure-functions-building-
scalable-and-serverless-apps-2nd-edition-rahul-sawhney/
Beginning Azure Functions: Building Scalable and

Serverless Apps 2nd Edition Rahul Sawhney
https://ebookmass.com/product/beginning-azure-functions-building-
scalable-and-serverless-apps-2nd-edition-rahul-sawhney-2/
Azure SQL Hyperscale
Revealed
High-performance Scalable Solutions
for Critical Data Workloads
Zoran Barać
Daniel Scott-Raynsford
Azure SQL Hyperscale Revealed: High-performance Scalable Solutions for Critical
Data Workloads
Zoran Barać Daniel Scott-Raynsford
Resolution Drive, Auckland, 0930, New Zealand Victory Road, Auckland, 0604, New Zealand
ISBN-13 (pbk): 978-1-4842-9224-2 ISBN-13 (electronic): 978-1-4842-9225-9

https://doi.org/10.1007/978-1-4842-9225-9
Copyright © 2023 by Zoran Barać and Daniel Scott-Raynsford

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with
every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an
editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the
trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not
identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to
proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of publication,
neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or
omissions that may be made. The publisher makes no warranty, express or implied, with respect to the
material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Jonathan Gennick
Development Editor: Laura Berendson
Editorial Assistant: Shaul Elson
Cover image by Felipe Portella from Unsplash
Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza,
Suite 4600, New York, NY 10004-1562, USA. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@
springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole
member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc
is a Delaware corporation.
For information on translations, please e-mail booktranslations@springernature.com; for reprint,
paperback, or audio rights, please e-mail bookpermissions@springernature.com.
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and
licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales
web page at www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is available to
readers on GitHub. For more detailed information, please visit www.apress.com/source-code.
Printed on acid-free paper
Table of Contents
About the Authors�� xi
About the Technical Reviewers�� xiii
Introduction��xv
Part I: Architecture�� 1
Chapter 1: The Journey to Hyperscale Architecture in Azure SQL�� 3
SQL on Azure�� 5
The Basics of Azure SQL�� 5
Azure SQL Platform as a Service�� 7
Deployment Models�� 9
Purchasing Models and Service Tiers�� 10
Availability Models and Redundancy�� 13
Standard Availability Model: Locally Redundant Availability�� 15
General Purpose Service Tier: Zone-Redundant Availability�� 16
Premium and Business Critical Service Tier: Locally Redundant Availability�� 18
Premium and Business Critical Service Tier: Zone-Redundant Availability�� 19
Protecting Against Regional Outages Using Failover Groups with
Geo-redundant Availability�� 21
The Hyperscale Service Tier�� 22
Hyperscale Architecture Overview�� 24
Deploying Your First Hyperscale Database�� 25
Cleaning Up�� 34
Summary�� 35
iii
Table of Contents
Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations�� 37

Hyperscale Azure SQL Scalability and Durability�� 38
Foundations of Azure SQL Hyperscale�� 40
The Buffer Pool Extension�� 41
The Resilient Buffer Pool Extension�� 41
Investigating the Size of RBPEX�� 41
Row Versioning–Based Isolation Level�� 45
Accelerated Database Recovery�� 48
Multitier Architecture Concepts in Hyperscale�� 49
Compute Nodes�� 50
Log Service�� 58
Page Servers�� 61
Azure Standard Storage�� 68
How Do the Tiers Work Together?�� 70
Summary�� 74
Part II: Planning and Deployment�� 75

Chapter 3: Planning an Azure SQL DB Hyperscale Environment�� 77
Considerations When Planning for Hyperscale�� 77
The Azure SQL Database Logical Server�� 78
Considerations for Reliability�� 81
Considerations for Network Connectivity�� 94
Considerations for Security�� 108
Considerations for Operational Excellence�� 119
Summary�� 124
Chapter 4: Deploying a Highly Available Hyperscale Database

into a Virtual Network�� 125
An Example Hyperscale Production Environment�� 126
The Starting Environment�� 129
The Starting Environment Deployment Script�� 131
iv
Table of Contents
Deploying the Starting Environment Using the Azure Cloud Shell�� 133
Creating a SQL Administrators Group�� 136
Deploying a Highly Available Hyperscale Database into a Virtual Network�� 139
Basic Configuration of the Database�� 141
Configuring Network Connectivity�� 146
The Final Configuration Tasks and Deployment�� 150
Deleting the Example Environment�� 155
Summary�� 157
Chapter 5: Administering a Hyperscale Database in a Virtual Network

in the Azure Portal�� 159
Administering a Hyperscale Database in a Virtual Network�� 160
Deploying a Management VM and Azure Bastion�� 163
Using the Management VM with an Azure Bastion�� 167
Summary�� 170
Chapter 6: Configuring Transparent Data Encryption to Bring Your Own Key�� 171
Enabling Customer-Managed Key Transparent Data Encryption�� 172
Creating a User-Assigned Managed Identity�� 174
Granting the Key Vault Crypto Officer Role to a User�� 175
Generating a Key in the Azure Key Vault�� 178
Granting Access to the Key by the User-Assigned Managed Identity�� 180
Assigning the User-Assigned Managed Identity to the Logical Server�� 182
Enabling Customer-Managed TDE�� 184
Summary�� 185
Chapter 7: Enabling Geo-replication for Disaster Recovery�� 187

Deploying a Hyperscale Geo Replica�� 188
Creating a Logical Server in the Failover Region�� 189
Connecting a Logical Server to a Virtual Network with Private Link�� 191
Enabling the Customer-Managed Key TDE�� 196
Enabling Geo-replication of a Hyperscale Database�� 198
Summary�� 200
v
Table of Contents
Chapter 8: Configuring Security Features and Enabling Diagnostic

and Audit Logs�� 203
Enabling Microsoft Defender for SQL�� 204
Storing Diagnostic and Audit Logs�� 206
Sending Audit Logs to a Log Analytics Workspace�� 207
Sending Database Diagnostic Logs to Log Analytics�� 209
Summary�� 211
Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell�� 213

Introduction to Infrastructure as Code�� 214
Imperative vs. Declarative Infrastructure as Code�� 215
Deploying Hyperscale Using Azure PowerShell�� 216
The Azure PowerShell Modules�� 216
Deploying the Starting Environment�� 218
The Complete Deployment PowerShell Script�� 218
Azure PowerShell Commands in Detail�� 220
Summary�� 239
Chapter 10: Deploying Azure SQL DB Hyperscale Using Bash and Azure CLI�� 241
Deploying Hyperscale Using the Azure CLI�� 241
The Azure CLI�� 242
Deploying the Starting Environment�� 243
The Complete Deployment Bash Script�� 245
Azure CLI Commands in Detail�� 247
Summary�� 264
Chapter 11: Deploying Azure SQL DB Hyperscale Using Azure Bicep�� 267
About Azure Bicep�� 268
Deploying Using Azure Bicep�� 268
A Complete Azure Bicep Deployment�� 268
Hyperscale Resources in Azure Bicep�� 271
Summary�� 284
vi
Table of Contents
Chapter 12: Testing Hyperscale Database Performance Against Other

Azure SQL Deployment Options�� 285
HammerDB�� 286
HammerDB TPROC-C Workload�� 287
HammerDB Step-by-Step�� 287
Schema Build Performance Metrics�� 301
TPROC-C Workload Metrics�� 312
Summary�� 336
Part III: Operation and Management�� 339

Chapter 13: Monitoring and Scaling�� 341
Monitoring Platform Metrics�� 342
Viewing Metrics with the Metrics Explorer�� 342
Streaming Metrics to a Log Analytics Workspace�� 344
Alerting on Platform Metrics�� 345
Monitoring and Tuning Database Performance�� 351
Monitoring Query Performance�� 351
Performance Recommendations�� 352
Automatically Tuning Database Performance�� 352
Gathering Insights from the Database�� 353
SQL Analytics�� 354
Scaling a Hyperscale Database�� 357
Manually Scaling Up a Hyperscale Database�� 358
Manually Scaling Out a Hyperscale Database�� 359
Autoscaling a Hyperscale Database�� 360
Summary�� 360
Chapter 14: Backup, Restore, and Disaster Recovery�� 361

Hyperscale Database Backups�� 361
Backup Retention Policy�� 362
Backup Storage Redundancy�� 365
Monitoring Backup Storage Consumption with Azure Monitor Metrics�� 367
vii
Table of Contents
Hyperscale Database Restores�� 368

Example 1: Restore to Same Region, LRS to LRS�� 369
Example 2: Restore to Same Region, LRS to GRS�� 371
Example 3: Restore to the Same Region, GRS to GRS�� 372
Example 4: Geo Restore to Different Region, GRS to LRS�� 372
Example 5: Geo-restore to Different Region, GRS to GRS�� 373
Comparing Restore Performance of Hyperscale to Traditional Azure SQL Databases�� 375
Disaster Recovery�� 377
Summary�� 379
Chapter 15: Security and Updating�� 381

Azure SQL Database Security Overview�� 381
Network Security�� 384
Access Management�� 387
Auditing and Azure Threat Detection�� 390
Information Protection�� 392
Updating and Maintenance Events�� 396
Summary�� 398
Chapter 16: Managing Costs�� 399

Azure Hybrid Benefit�� 399
Reserving Capacity�� 401
Purchasing Reserved Capacity�� 401
Estimating Reserved Capacity Benefits�� 402
Utilizing Reservations�� 402
Scaling In and Scaling Down Replicas�� 403
Summary�� 405
Part IV: Migration�� 407

Chapter 17: Determining Whether Hyperscale Is Appropriate�� 409
Key Considerations for Hyperscale�� 409
Scalability�� 410
Reliability�� 413
viii
Table of Contents
Business Continuity�� 413

Cost�� 416
Summary�� 418
Chapter 18: Migrating to Hyperscale�� 419

Common Migration Methods�� 419
In-Place Conversion of an Azure SQL Database to Hyperscale�� 421
Migrating to Hyperscale with Data Migration Assistant�� 425
Migrating to Hyperscale with the Azure Database Migration Service�� 432
Migrating with ADS with the Azure SQL Migration Extension�� 443
Migrating to Hyperscale Using Import Database�� 444
Migrating to Hyperscale Using a Data Sync and Cutover�� 446
Summary�� 447
Chapter 19: Reverse Migrating Away from Hyperscale�� 449

Reverse Migration Methods�� 450
Reverse Migration Using the Azure Portal�� 450
Reverse Migration Using Transact SQL�� 453
Reverse Migration Using Azure CLI�� 454
Common Pitfalls of the Reverse Migration Process�� 456
Migrating to an Unsupported Service Tier�� 456
Database Not Eligible for Reverse Migration�� 457
Summary�� 457
Chapter 20: Conclusion�� 459
Index�� 461
ix
About the Authors
Zoran Barać is a cloud architect and data specialist
with more than 15 years of hands-on experience in
data optimization, administration, and architecture. He
is a Certified Microsoft Trainer (MCT) and Microsoft
Certified Solutions Expert (MCSE) with a master‘s degree
in information technology. Sharing knowledge and
contributing to the SQL Server community are his passions.
He is also an organizer of the Auckland SQL User Meetup
Group, an active blogger, and a speaker at different SQL events such as Data Summits,
SQL Saturdays, SQL Fridays, meetups, etc.
Daniel Scott-Raynsford is a partner technology strategist

at Microsoft with 15 years of experience as a software
developer and solution architect. He specializes in DevOps
and continuous delivery practices. He was a Microsoft MVP
in cloud and data center management for three years before
joining Microsoft and is an active PowerShell open-source
contributor and Microsoft DSC Community Committee
member. He is also a contributor to the Azure Architecture
Center on multitenant architecture practices.
xi
About the Technical Reviewers
Jonathan Cowley is a cloud infrastructure engineer,
DevOps practitioner, and technical documentation writer
with more than 15 years of experience in various roles and
environments, in both small and large corporations and
public organizations. He has been Microsoft Azure and AWS
certified. He enjoys connecting people and information and
solving challenging problems.
Vitor Fava has earned the title of Most Valuable Professional

(MVP AI and Data Platform) and the main certifications
related to SQL Server, such as MCP, MCTS, MCITP, MCSA,
and MCSE. A DBA with more than 20 years of experience
in database and information technology, Vitor works on
the development, implementation, maintenance, and
support of large corporate database servers. Vitor graduated
with a degree in information systems from Universidade
Presbiteriana Mackenzie/SP, with an emphasis on high-
performance and mission-critical database environment
management.He has been a speaker at several technology events, such as SQLBITS,
SQL Saturday, The Developers Conference (TDC), SQL Porto, InteropMix, and several
discussion groups focused on database technology. Vitor also provides advanced
training in SQL Server and Azure SQL Database, in addition to acting as an MCT
in official Microsoft training. He is also the chapter leader of the PASS Chapter SQL
Maniacs in São Paulo, Brazil.
xiii
Introduction
Azure SQL is a platform-as-a-service (PaaS) relational database management system
(RDBMS) that is provided as part of the Azure cloud and based on the Microsoft SQL
Server platform. This offering contains service tiers that make it suitable for a wide
range of use cases, from small single-user applications to mission-critical lines of
business workloads. However, there is only one service tier that provides the high level
of scalability and resilience that is required by some of today’s largest cloud-based
workloads: Hyperscale.
In this book, we’ll take you through the capabilities and basics of the Azure SQL
Database Hyperscale service tier. You’ll learn the basics of designing, deploying, and
managing Azure SQL Hyperscale databases. We’ll look in detail at the resilience (high
availability and disaster recovery) and scalability of Azure SQL Hyperscale databases and
how to tune them. We will also look at the different techniques you can use to deploy and
configure Azure SQL Hyperscale.
Monitoring and securing Azure SQL Hyperscale databases will also be covered to
ensure your workloads continue to perform and operate securely. This book will be your
guide to deciding when Hyperscale is a good fit for migrating your existing workloads
and what architectural considerations you should make in your application. Finally,
you’ll learn how to migrate existing workloads to Azure SQL Database Hyperscale.
This book is intended for data architects, software engineers, cloud engineers,
and site reliability engineers and operators to learn everything they need to know to
successfully design, deploy, manage, and operate Azure SQL Database Hyperscale.
You’ll learn what makes Azure SQL Database Hyperscale architecture different
from a more traditional database architecture and why it’s important to understand the
architecture.
To get the most out of this book, you should have a basic knowledge of public cloud
principles and economics as well as a fundamental knowledge of Azure, Microsoft SQL
Server, and RDBMSs. It is not required to have experience using Azure SQL Database.
This book will provide you with everything you need to know to effectively build and
operate the Hyperscale tier of Azure SQL Database without prior experience.
xv
Introduction
Although this book covers concepts that apply to Azure SQL Database in general,
it is intended to provide everything you need to know to run an Azure SQL Database
Hyperscale tier in Azure without requiring any other material. You may find content that
is covered in other more general books on running SQL in Azure, but this book looks at
these concepts through the Hyperscale lens. Hyperscale has special use cases that make
it unique, which also require specific knowledge to get the most out of it.
Thank you for venturing into the world of Hyperscale database technology.
A note about the recently announced automatic compute scaling with serverless for
Hyperscale in Azure SQL Database: At the time of writing this book, the possibility of
an automatically scaling Hyperscale with a serverless compute tier was merely an item
on the roadmap. We did not, therefore, cover it in detail, even though we were aware it
was planned. However, serverless Hyperscale has just arrived in public preview. This
development does not change the guidance provided in this book, but serverless should
be considered for Hyperscale workloads that need high levels of elasticity. It is yet another
tool in the amazing array of data storage services available in Microsoft Azure and should
be on your list of considerations when determining if Hyperscale is right for you.
Serverless Hyperscale automatically adjusts the compute resources of a database
based on its workload and usage patterns. It also allows different replicas of the
database to scale independently for optimal performance and cost efficiency. Serverless
Hyperscale is different from provisioned compute Hyperscale, which requires a fixed
number of resources and manual rescaling.
For more information on the serverless Hyperscale announcement, see this page
https://techcommunity.microsoft.com/t5/azure-sql-blog/automatic-compute-
scaling-with-serverless-for-hyperscale-in/ba-p/3624440.
xvi
CHAPTER 1
The Journey to
Hyperscale Architecture
in Azure SQL
Every day, many billions or even trillions of transactions are processed by the ever-
growing number of Azure SQL databases deployed globally in the Microsoft Azure public
and government clouds. The number of transactions and the size of these databases
are continuously increasing. The accelerating adoption of public cloud technology has
enabled new use cases for Azure SQL databases as well as the migration of larger line-of-
business applications from on-premises SQL servers.
As the public cloud continues to mature, businesses are moving more of their
mission-critical workloads to Azure. This results in the need to support larger and larger
databases.
Accompanying this move to the cloud, the demand for IT departments and
engineering teams to provide more application features with greater resilience and
security has also increased. This pressure has caused organizations to look at how
they can cut down on the operational costs of maintaining their infrastructure. The
requirement to reduce operational expenditure has led toward running more databases
as platform-as-a-service (PaaS) solutions—where the cloud provider takes care of the
day-to-day operations of the infrastructure—freeing the organization to focus on higher-
value tasks.
As well as the migration of enterprise-scale databases, an increase in the adoption
of software-as-a-service (SaaS) solutions by consumers and organizations has led to
SaaS providers needing larger databases, higher transaction throughput, and increasing
resilience—while also being able to scale quickly.
3
© Zoran Barać and Daniel Scott-Raynsford 2023
Z. Barać and D. Scott-Raynsford, Azure SQL Hyperscale Revealed,
https://doi.org/10.1007/978-1-4842-9225-9_1
Chapter 1 The Journey to Hyperscale Architecture in Azure SQL
This explosive shift by organizations to adopting SaaS has also facilitated a need by
SaaS providers to manage costs as they scale. This has often resulted in a change from a
single database per tenant to a multitenant approach. A multitenant approach can help
to reduce costs, but it also increases the need for larger capacities and throughput, while
being able to assure isolation and avoid challenges such as noisy neighbors. For an in-
depth explanation on that, see https://learn.microsoft.com/azure/architecture/
antipatterns/noisy-neighbor/noisy-neighbor.
The growth trend toward SaaS is expected to continue as organizations and SaaS
providers accommodate the expectations of their customers to gain greater value
from their data with analytics and machine learning. This growth in demand for better
analytics and machine learning abilities also facilitates the need to collect more data,
such as usage telemetry and customer behavior data.
New types of application workloads and patterns, such as event streaming
architectures and the Internet of Things (IoT), have also increased the demands on
relational database management systems. Although alternative architectures exist to
reduce the impact of these application workloads on the relational database, they don’t
completely mitigate the need for larger relational databases as a part of applications.
Customers are expecting solutions that can integrate with and accept data from other
services and data sources. This is leading organizations and SaaS providers to build a
greater level of integration into their software and also to be seen as platforms with an
ecosystem of third-party applications and extensions springing up around them. This is
further pushing the scale and elasticity required by the relational database management
system (RDBMS) underlying these platforms.
Applications are also consuming data from more and more systems and providing
their own combined insights and enhancements. For example, applications that
integrate with Microsoft Teams might retrieve calling and messaging data and combine
it with other data sources to provide additional functionality. As the volume of data
increases within these systems, so does the need for more capacity in the application
database that collects it.
Azure provides the Azure SQL Database service, a PaaS product, that includes
several different tiers offering options for capacity and resilience while also enabling a
high degree of scale.
The changing data landscape, driven by the cloud, SaaS, and newer workloads, has
resulted in the need for a design change to the Azure SQL Database architecture to be
pushed to the limit, requiring a completely new internal architectural approach: the
Hyperscale architecture.
4
Hyperscale is the newest service tier of the Azure SQL Database and provides
highly scalable compute and storage that enables it to significantly exceed the limits of
the other tiers of service. This is achieved by substantial alterations to the underlying
architecture. These changes are discussed in more detail in Chapter 2.
Tip Throughout this book we’ll often refer to the Azure SQL Database Hyperscale
service tier as just Hyperscale to make it easier on you, the reader.
At its core, Hyperscale helps us address these changing requirements, without

the need to adopt radically different architectures or fundamentally change our
applications—which in this new world of high demand for applications and features is a
great thing.
SQL on Azure
It’s been a long and progressive journey of more than 12 years from the beginnings of
Azure SQL called CloudDB all the way up to the new Azure SQL Database Hyperscale
service tier and Hyperscale architecture.
Before we can get into the details of Hyperscale, we will start by looking at the
different ways that SQL workloads can be hosted in Azure. This will give us a view of
where Hyperscale fits within the portfolio and when it is a good choice for a workload.
The Basics of Azure SQL

There are many benefits to hosting your data workloads in the cloud. Whether you
want to utilize modern cloud offerings using Azure SQL Database, migrate an existing
workload and retain your current SQL Server version running on an Azure virtual
machine (VM), or simply adopt the newest SQL Server features, Azure SQL might be the
right choice for you.
Fundamentally, there are two distinct ways SQL workloads can be deployed in Azure.
• As infrastructure as a service (IaaS) using SQL Server on Azure VMs

• As a platform as a service (PaaS) using Azure SQL Database (DB) or
Azure SQL Managed Instance (MI)
5
Both Azure SQL deployment types (IaaS and PaaS) offer you redundant, secure, and
consistent cloud database services. However, with IaaS you are responsible for more of
the system, requiring a greater amount of effort from you in maintaining and ensuring
the system is resilient and secure.
Tip Azure SQL MI is a PaaS database service with a higher level of isolation and
compatibility with SQL Server on Azure VMs or on-premises SQL Servers.
Running SQL Server on Azure VMs provides you with the ability to configure every
aspect of the underlying infrastructure, such as compute, memory, and storage as well
as the operating system and SQL Server configuration. This high level of configurability
comes with an increased operational cost and complexity. For example, operating
system and SQL Server upgrades and patching are the user’s responsibility.
By comparison, Azure SQL DB (and Azure SQL MI) is a managed database service
where users do not need to worry about SQL Server maintenance tasks—such as
upgrades, patching, or backups—or service availability. The Azure platform abstracts
and manages these important aspects of your environment automatically, significantly
reducing operational costs and complexity. This often results in a much lower total cost
of ownership (TCO).
Generally, PaaS provides significant benefits that make it extremely attractive;
however, in some cases, IaaS is still required. Some applications might need access to the
underlying SQL instance or features of SQL Server that are not available on Azure SQL DB.
Tip For some workloads that need features that Azure SQL DB does not provide,
Azure SQL MI might still be an option. This could still allow the workload to be
moved to Azure, while leveraging the significant benefits of PaaS. For a comparison
between Azure SQL DB and Azure SQL MI features, see https://learn.
microsoft.com/azure/azure-sql/database/features-comparison.
Workloads that are being migrated from on-premises or a private cloud often require
IaaS when they are first migrated into Azure but will be able to be re-platformed onto
Azure SQL DB after some modernization. The benefits of this usually far outweigh the
engineering costs of modernization. Another reason that IaaS might be needed is to gain
a higher level of infrastructure isolation for regulatory compliance reasons.
6
Figure 1-1 compares the administration needs and costs of on-premises, private
cloud machines, IaaS, and PaaS. We can see that PaaS has lower administration needs
and costs than IaaS.
Figure 1-1. Continuum of cost and administration of different hosting models
We will be focusing primarily on Azure SQL DB, as this is the only deployment model
that supports the newest service tier: Hyperscale.
Azure SQL Platform as a Service

When you select Azure SQL PaaS, you are getting a fully managed database service.
Whichever deployment model you choose, you will always have some level of
redundancy, starting with local redundancy and if available zone or geo-redundancy.
7
There are four key decisions you need to make when deploying a SQL workload
on Azure.
1. Choose a deployment model.
2. Specify a purchasing model.
3. Specify a service tier.
4. Choose an availability model; this will depend on which service
tiers you deployed.
Figure 1-2 shows a map of the deployment models, purchasing models, service tiers,
and availability models available when selecting Azure SQL PaaS. As this book is all
about Hyperscale, the most important area is the Hyperscale service tier.
Figure 1-2. Azure SQL DB deployment models, purchasing models, service tiers,
and availability models
8
Deployment Models
The PaaS deployment models are divided into two types.
• Azure SQL Database
• Azure SQL Managed Instance
When you deploy an instance of Azure SQL DB, you have two deployment options:
a single database or elastic pools. When using elastic pools, you can allow multiple
databases to share a specified number of resources at a set price.
Tip Elastic pools are an excellent model for building SaaS applications, where
each tenant has their own database; however, elastic pools don’t currently support
Hyperscale.
Azure SQL MI offers both single-instance and instance pool deployment options.
Single instance supports only a single SQL Server instance, while instance pools allow
multiple SQL Server instances.
Table 1-1 shows the deployment options available with Azure SQL PaaS, as well as
the features and recommended use cases.
9
Table 1-1. Azure SQL PaaS Deployment Options

Managed Instances Databases
Single Instance Instance Pool Single Database Elastic Pool
• Fully managed service.
• Minimum four • Hosting instance • Hyperscale Service • Price optimization—
vCores per instance. with smaller core tier availability. shared resources.
• 16TB size storage number (two • Serverless compute • Ability to limit
for the General vCores). tier for the General necessary resources
Purpose service tier. Purpose service tier. per database.
• Supports most on-premises instance/ • The most used SQL Server features are
database-level capabilities. supported.
• High compatibility with SQL Server • 99.99 percent to 99.995 percent availability
on-premises. guaranteed.
• At least 99.99 percent availability • Built-in backups, patching, recovery.
guaranteed. • Latest stable database engine version.
• Built-in backups, patching, recovery.
• Latest stable database engine version.
• Easy migration from SQL Server.
Tip You can use the Azure Portal to check the usage and properties for an
existing MI pool, but not to deploy a pool. Instead, use a PowerShell session or the
Azure CLI.
Purchasing Models and Service Tiers

Within Azure SQL all deployment offerings are provisioned on virtual infrastructure.
Purchasing models and service tiers define the back-end hardware capabilities for specific
deployments, such as machine instance and CPU generation, vCores, memory, and
capacity. You need to consider the ideal hardware configuration based on your workload
requirements. The exact offerings can vary depending on your deployment region.
10
Figure 1-3 shows the compute tier and hardware configuration for the General
Purpose service tier for the Azure SQL Database deployment option.
Figure 1-3. Service and compute tier: Azure SQL DB General Purpose service tier
There are two different purchasing models—vCore and DTU—each with multiple
service tiers. The DTU purchasing model is based on data transaction units (DTUs).
DTUs are a blended measurement of a machine’s specifications—CPU, memory, reads,
and writes. Figure 1-4 shows available purchasing models and service tiers for single
Azure SQL Database deployment.
11
Figure 1-4. Single Azure SQL DB purchasing models and service tiers available
Tip For more information on DTU modeling, review this page: https://learn.
microsoft.com/azure/azure-sql/database/service-tiers-dtu.
There are multiple service tier options within the DTU purchasing model:
• Basic: Use for less demanding workloads: up to 5 DTU, up to 2GB

data, read latency of 5ms, and write latency of 10ms.
• Standard: Use for workloads with typical requirements: up to 3000

DTUs (S12), up to 1TB data, read latency of 5ms, and write latency
of 10ms.
• Premium: Use for I/O-intensive workloads: up to 4000 DTUs, up to

4TB data, read and write latency of 2ms, read scale-out and zone-
redundant options available.
The vCore purchasing model represents a choice of specific virtual hardware

specifications. You select the generation of the hardware—starting with the CPU
configuration, number of cores, maximum memory, and storage capacity. This model is
transparent and cost efficient and gives you the flexibility to translate your on-premises
workload infrastructure requirements to the cloud.
12
There are multiple service tier options within the vCore purchasing model.
• General Purpose
• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

4TB data.
• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore,

and up to 16TB data. Premium-series 7GB RAM/vCore, and up to
16TB data.
• Azure SQL DB Serverless: 0.5–80 vCores, up to 240GB memory,

and up to 4TB data.
• Business Critical
• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

4TB data.
• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore

and up to 4TB data. Premium-series 7GB RAM/vCore, and up to
16TB data.
• Hyperscale
• Standard-series (Gen5): 2–80 vCores, up to 415GB memory, and

up to 100TB data.
• Premium-series: 2–128 vCores, up to 625GB memory, and up to

100TB data.
• Premium-series memory-optimized: 2–128 vCores, up to 830GB

memory, and up to 100TB data.
• DC-series (enables confidential computing): 2–8 vCores, up to

36GB memory, and up to 100TB data.
You can choose the vCore purchasing model only for managed instances with the
General Purpose or Business Critical service tier.
Availability Models and Redundancy

There are two main availability models in Azure SQL PaaS offerings.
13
• Standard: Separates compute and storage tiers. It relies on the

high availability of the remote storage tier. This can result in some
performance degradation during maintenance activities, so it is
suitable for more budget-conscious users.
• Premium: Like the Always On availability option for VMs. It relies on

a failover cluster of database engine processes. It is more reliable as
there is always a quorum of available database engine nodes. This
suits mission-critical applications with high I/O performance needs.
It minimizes any performance impact to your workload during
maintenance activities.
Depending on which service tiers you deployed, it may leverage the Standard
availability architecture for the Basic, Standard, and General Purpose service tiers or the
Premium availability architecture for the Premium and Business Critical service tiers.
There are three types of redundancy when running SQL workloads in Azure.
• Local redundancy: All Azure SQL PaaS deployments offer local

redundancy. Local redundancy relies on the single data center being
available.
• Zone redundancy: This replicates a database across multiple

availability zones within the same Azure region. Azure availability
zones are physically separate locations within each Azure region that
are tolerant to local failures. To enable zone redundancy, you need to
deploy your services within a region that supports availability zones.
This protects your workload against failure of a single availability
zone. For more information on Azure availability zones, see this page:
https://learn.microsoft.com/azure/availability-zones/az-
overview.
• Geo-redundancy: There are multiple ways to achieve geo-redundancy

using failover groups (FOGs) or active geo-replication. Geo-
replication is an Azure SQL Database business continuity and
disaster recovery feature (asynchronous replication). This protects
your workload against failure of an entire region.
14
Tip Zone-redundant configuration is available only for Azure SQL Database

deployment and only for Gen5 hardware or newer. Using zone-redundant
configuration with SQL Managed Instance is not currently supported.
Depending on which service tier you select, it may leverage either the Standard or
Premium availability architecture model.
• Standard availability model: DTU purchasing model Basic and

Standard service tiers and vCore purchasing model General Purpose
service tier
• Premium availability model: DTU purchasing model Premium

service tier and vCore purchasing model Business Critical
service tiers
tandard Availability Model: Locally

S
Redundant Availability
Basic, Standard, and General Purpose service tiers leverage the Standard availability
model, which offers resilience to failure using locally redundant remote Azure Premium
storage to store data and log files (.mdf and .ldf files). Backup files are stored on geo-
redundant Azure Standard storage. High availability is accomplished in a similar way
for the SQL Server Failover Cluster Instance (FCI), by using shared disk storage to store
database files.
Figure 1-5 shows the Azure SQL PaaS Standard availability model architecture used
by the Basic, Standard, and General Purpose service tiers.
15
Figure 1-5. Azure SQL PaaS Standard availability model architecture
General Purpose Service Tier: Zone-Redundant Availability

Like Basic and Standard, the General Purpose service tiers leverage the Standard availability
model. In addition to local redundancy, which is included with all Azure SQL PaaS
deployment options, the General Purpose service tiers can offer zone redundancy as well.
This provides resilience to failure across different availability zones within the same
region. Zone-redundant configuration for serverless and provisioned General Purpose
tiers are available in only some regions.
16
Tip Be aware that with the General Purpose service tier, the zone-redundant
option is available only when the Gen5 (or newer) hardware configuration is
selected. Selecting zone redundancy incurs an additional cost.
Figure 1-6 shows the Azure SQL PaaS Standard availability model with zone
redundancy used by the General Purpose service tier.
Figure 1-6. Azure SQL PaaS Standard availability model with zone
redundancy enabled
17
remium and Business Critical Service Tier: Locally

P
Redundant Availability
The Premium and Business Critical service tiers leverage the Premium availability
model, which offers resilience to failure using multiple replicas in synchronous data
commit mode. Every replica has integrated compute and storage, which means that
every node has an attached solid-state disk (SSD) with databases and log files on it (.mdf
and .ldf files). High availability is accomplished in a similar way as with SQL Server
Always On availability groups, by replicating nodes across the cluster using synchronous
data commit mode.
Figure 1-7 shows the Azure SQL PaaS Premium availability model architecture used
by the Premium and Business Critical service tiers.
18
Figure 1-7. Azure SQL PaaS Premium availability model architecture
remium and Business Critical Service Tier:

P
Zone-Redundant Availability
As mentioned earlier, the Premium and Business Critical service tiers leverage the
Premium availability model, which offers resilience to failure using multiple replicas
in synchronous data commit mode. Moreover, the zone-redundant deployment option
provides additional resilience to an Azure availability zone (AZ) failure, if the failure is
19
confined to a single AZ rather than an entire region. High availability is accomplished

in a similar way for SQL Server Always On availability groups, replicating nodes across
multiple availability zones in synchronous data commit mode.
Tip Azure SQL Database service tiers using the Standard availability model
provides a greater than 99.99 percent uptime availability guarantee. Nevertheless,
Premium and Business Critical service tiers—leveraging the Premium availability
model with zone-redundant deployments—provide a greater than 99.995 percent
uptime guarantee.
Figure 1-8 shows the Azure SQL PaaS Premium availability model with zone
redundancy enabled for the Premium and Business Critical service tiers.
20
Figure 1-8. Azure SQL PaaS Premium availability model with zone
redundancy enabled
rotecting Against Regional Outages Using Failover

P
Groups with Geo-redundant Availability
To protect your SQL instance against failure of an entire Azure region and to achieve
geo-redundancy with good disaster recovery capability, you can use failover groups.
Failover groups enable asynchronous replication between multiple Azure regions (or
within regions).
21
Figure 1-9 shows geo-replication using failover groups via asynchronous replication
between multiple Azure regions.
Figure 1-9. Geo-replication between multiple Azure regions using failover groups
The Hyperscale Service Tier

A traditional monolithic cloud architecture has its purposes but has several limitations,
in particular relating to large database support and length of recovery time. For the
past decade, Microsoft has been aiming to develop a new architecture model that can
override these issues.
22
The goal of the new model has been to decouple compute, storage, and log services,
while at the same time offering highly scalable storage and compute performance tiers.
At the time of writing, there is an Azure SQL database deployment model and the
Hyperscale service tier under the vCore purchasing model, which leverages a new
architecture, which in this book we will call the Hyperscale architecture.
Table 1-2 compares the traditional Azure SQL architecture and the Azure Hyperscale
architecture.
Tip Hyperscale is available only under the Azure SQL Single Database

deployment option; you cannot use the Hyperscale service tier with elastic pool
deployment.
Table 1-2. Traditional Azure SQL Architecture vs. Azure Hyperscale Architecture
Traditional Architecture Hyperscale Architecture
Max Azure SQL DB: 4TB. 100TB.

Storage Azure SQL MI Business
Size Critical: 5.5TB.
Azure SQL MI General
Purpose: 16TB.
CPU Up to 128 vCores. Standard-series (Gen5): Up to 80 vCores.
Premium-series: Up to 128 vCores.
Memory Standard-series (Gen5): Standard-series (Gen5): up to 415.23 GB memory.
up to 625 GB memory. Premium-series: up to 625 GB memory.
Premium-series (memory optimized): up to 830.47 GB
memory.
Latency Premium availability Latency can vary and mostly depends on the workload and
model: 1–2ms. usage patterns.
Standard availability Hyperscale is a multitiered architecture with caching at
model: 5-10ms. multiple levels, data being accessed primarily via a cache
on the compute node. In such cases, average latency will
be similar as for Business Critical or Premium service tiers
(1–2ms).
(continued)
23
Table 1-2. (continued)
Traditional Architecture Hyperscale Architecture
Log Depending on vCores 105MB/s regardless of the number of vCores.

Throughput number.
Up to 96 MB/s per node.
Log Size Up to 1TB log size. Unlimited log size.
Read 1 read scale-out replica. Up to 4 HA/Read scale-out replicas.
scale-out Up to 30 named replicas.
Backup Depending on database Snapshot-based backup and restore operations do not
and size. depend on database size.
Restore
Tip The main question you should ask yourself is whether your data workload
demands are exceeding the limits of your current Azure SQL service tier—in which
case you might consider moving your data workload to a more suitable service tier
such as Azure SQL Hyperscale, leveraging the Hyperscale architecture scale-out
capability.
Hyperscale Architecture Overview

Azure SQL Hyperscale utilizes the four-tier architecture concept, which includes the
remote durable storage service to achieve superior performance, scalability, and
durability. Figure 1-10 shows the four-tier Hyperscale architecture concept of decoupling
the compute layer from log services and scale-out storage.
24
Figure 1-10. Four-tier Hyperscale architecture concept
Deploying Your First Hyperscale Database

Now that we have covered the basic options available when deploying a SQL workload
in Azure, it’s time to provision our very first Hyperscale database. For this, we’re going to
use a user interface–driven process in the Azure Portal.
25
Tip Deploying services using the Azure Portal is a great way to get started,
but it is strongly recommended that as you mature in your use of Azure, you
adopt infrastructure as code. To learn more about infrastructure as code,
refer to https://learn.microsoft.com/devops/deliver/what-is-
infrastructure-as-code. We will favor using infrastructure as code in the
examples throughout this book.
You will need access to an Azure subscription that you have appropriate permissions
to create new services in. The Contributor or Owner role in the Azure subscription will
be adequate permissions. If you’re not the subscription owner, you should first check
with the account owner for the subscription if you may deploy a Hyperscale database as
there will be a cost for every hour that you have the service deployed.
Tip If you don’t have access to an Azure subscription, you can sign up for a free
Azure one with USD $200 credit to use within 30 days; see https://aka.ms/
AzureFree. After you have consumed the USD $200 credit, the free services will
still be available to you for one year, but unfortunately the Hyperscale tier of Azure
SQL DB is not currently among the free services.
The Azure Portal is under constant improvements, and it is quite possible that the
user interface you see by the time this book is released will be slightly different. But
the fundamental elements should remain. That is a reason why we will provide many
examples as code.
In our example, we’re going to deploy a zone-redundant Hyperscale database with
two vCores running on Gen5 hardware in the Azure East US region with one high-
availability secondary replica.
So, let’s get started.
1. Open your browser and navigate to https://portal.azure.com.
2. Sign in using credentials that give you access to the Azure
subscription you’ll be deploying your Hyperscale database into.
3. Click the “Create a resource” button in the home dashboard.
26
4. Click Create under SQL Database on the “Create a

resource” blade.
5. The Create a SQL Database blade will open showing the Basics
configuration options of our database.
27
6. Make sure Subscription is set to the name of the subscription you

have permission to deploy into.
7. Set the resource group to an existing resource group that you want
to create your Hyperscale database into or click New to create
a new resource group. In our example, we are going to create
our hyperscale resources in an existing resource group called
sqlhyperscalerevealed-rg that is in the Azure East US region.
8. Enter the name of the Hyperscale database to create in the

“Database name” box. We are using hyperscaledb for this
example.
9. Although Azure SQL Database is a PaaS service, there is still
an underlying SQL Database server. We need to create a new
logical instance of a SQL Database server by clicking the “Create
new” button.
28
10. Every SQL Database server must have a unique name, not just
within our environment, but globally. For this example, we are
using sqlhyperscalerevealed01, but you should use a name that
is likely to be globally unique.
11. Set the location to the Azure region in which you want to deploy
the SQL Database server. This is the Azure region where your
Hyperscale database will be stored and should usually be as
geographically close to your application or users as possible.
Important Azure SQL Database Hyperscale is enabled in most Azure

regions. However, if it is not enabled in the region you chose, select an
alternate region, or see this page for more information: https://learn.
microsoft.com/azure/azure-sql/database/service-tier-
hyperscale?view=azuresql#regions.
12. Set the authentication method to “Use only Azure Active Directory
(Azure AD) authentication.”
Tip You can choose to use SQL authentication or to use both SQL and Azure AD
authentication, but it is recommended you use Azure AD authentication to enable
the central management of identities. However, some third-party applications may
not support this. We will cover security best practices in detail in Chapter 15.
13. Click the “Set admin” button to select the Azure AD user or
group that will be granted the admin role on this SQL Database
server. But for this example, we will select our own Azure AD user
account to be the admin.
Tip It is good practice to set the admin role to a separate Azure AD group that is
created for this SQL Database server. Membership in this group should be carefully
governed.
29
14. Click OK on the Create SQL Database Server blade.
15. We will return to the Create SQL Database blade to continue

configuration.
16. As noted earlier in this chapter, Hyperscale does not support

elastic pools, so specify No when asked if we want to use SQL
elastic pools.
17. Select the Production environment. This affects the default
compute and storage options that are suggested for the database.
However, because we are going to specify Hyperscale, we can’t
accept the defaults anyway.
18. Click the “Configure database” button. This will open the
Configure blade.
19. Set the service tier to “Hyperscale (On-demand scalable storage).”
30
20. The Hardware Configuration option should be set to “Standard-

series (Gen5).”
21. We can leave the vCores option set to 2.
22. Set High-Availability Secondary Replicas to 1 Replica.
23. Specify Yes when asked if you would like to make this database
zone redundant.
24. Click the Apply button.
25. We will return to the Create SQL Database blade again. We will not
change any of the other deployment options, such as Networking
and Security for this example, as we can change most of them
after deployment.
31
26. Click the “Review + create” button.
27. Review the estimated cost per month and scan through the
configuration to confirm we’re configuring what we expected.
There are ways to reduce the estimated cost per month (such
as purchasing reserved capacity), but these will be discussed in
Chapter 16.
Important The Azure SQL Database Hyperscale tier is billed hourly. So, once the
resources are deployed, you’ll begin to be billed. Deleting the database resource
will cause you to stop being billed, but you will be charged for at least one hour.
28. Click the Create button.
29. After a few seconds, our resources will begin to be deployed, and a
deployment progress window will be displayed.
32
30. Once the deployment has been completed, we can click the
sqlhyperscalerevealed01/hyperscaledb resource (or whatever
you called it in your subscription) to be taken directly to the
database.
31. We will be taken to the Overview blade of our new Hyperscale

database.
Congratulations! You have deployed your first Hyperscale database and can begin
to use it. There are other administrative tasks we would typically do from here, such
as granting access to the database and opening network access to our applications
and users, but they will all be covered in later chapters. For now, this is enough to
demonstrate just how easy it is to get a Hyperscale database up and running in Azure.
33
Another random document with
no related content on Scribd:
The Project Gutenberg eBook of The binding of
the Nile and the new Soudan

This ebook is for the use of anyone anywhere in the United States
and most other parts of the world at no cost and with almost no
restrictions whatsoever. You may copy it, give it away or re-use it
under the terms of the Project Gutenberg License included with this
ebook or online at www.gutenberg.org. If you are not located in the
United States, you will have to check the laws of the country where
you are located before using this eBook.
Title: The binding of the Nile and the new Soudan
Author: Sidney Cornwallis Peel
Release date: October 5, 2023 [eBook #71808]
Language: English
Original publication: London: Edward Arnold, 1904
Credits: Galo Flordelis (This file was produced from images

generously made available by The Internet Archive)
*** START OF THE PROJECT GUTENBERG EBOOK THE

BINDING OF THE NILE AND THE NEW SOUDAN ***
THE BINDING OF THE NILE
AND
THE NEW SOUDAN

Mehemet Ali,
from a painting in the
possession of the Oriental Club.
LONDON: EDWARD ARNOLD: 1904.
THE
BINDING OF THE NILE

AND
THE NEW SOUDAN
BY THE HON.
SIDNEY PEEL
Late Fellow of Trinity College, Oxford
Author of ‘Trooper 8008 I.Y.’
LONDON
EDWARD ARNOLD
Publisher to H. M. India Office
1904
[All rights reserved]
PR EFACE
I have tried to tell in outline the story of the regulation of the Nile and
some of its consequences. A rash project, perhaps, for one who is
not an engineer; but, then, this book is not written for engineers, and
politics enter largely into it.
I have had some special opportunities of observation, and I have
many friends to thank for the help which they have given me. In
particular I am much indebted to the Standard, whose special
correspondent in Egypt and the Soudan I had the good fortune to be
during a part of 1902-1903.
Anyone who wishes to gain a real acquaintance with the
principles and details of Egyptian Irrigation should read the
monumental and interesting work by Sir W. Willcocks, K.C.M.G., on
that subject, to which my indebtedness is large.
The standard work on the Soudan is not yet written. There is but
one man who combines the necessary knowledge, experience, and
attainments to do it, and he, fortunately for the Soudan, is—and will
be for a long time to come—too fully occupied with his arduous and
multifarious duties. I mean, of course, the present Governor-General,
Sir Reginald Wingate. No official of the Soudan Government, least of
all he, has leisure to write a book; but I sincerely hope that the
materials for it are steadily collecting.
S. P.
C O NT ENT S
PART I

CHAPTER PAGE
I. THE NILE 3
II. BASIN IRRIGATION 13
III. PERENNIAL IRRIGATION 23
IV. THE CULTURE OF THE FIELDS 32
V. THE DELTA BARRAGE AND THE ENGLISH ENGINEERS 43
VI. THE CORVÉE 59
VII. RESERVOIR PRELIMINARIES 68
VIII. THE DAM AND THE NEW BARRAGES 81
IX. THE INAUGURATION OF THE RESERVOIR 91
X. BRITISH RULE IN EGYPT 101
XI. SCHEMES FOR THE FUTURE 111
XII. THE SUDD 124
XIII. THE UNITY OF NILELAND 134
PART II
THE NEW SOUDAN

XIV. THE PAST 139
XV. THE PAST—continued 159
XVI. THE NEW KHARTOUM 173
XVII. THE NEW SOUDAN 185
XVIII. JUSTICE AND SLAVERY 200
XIX. EDUCATION AND THE GORDON COLLEGE 214
XX. TRADE AND COMMERCE 226
XXI. TAXATION, REVENUE, AND EXPENDITURE 247
XXII. THE COST OF THE SOUDAN TO EGYPT 261
XXIII. CONCLUSION 270
INDEX 278
MAP OF EGYPT AND THE SOUDAN At end
PORTRAIT
MEHEMET ALI Frontispiece
(From the painting by T. Brigstock in the possession of the Oriental
Club.)
PART I
CHAPTER I
THE NILE
Far back in the world’s history a fracture of the earth’s crust took
place in the region which is now Egypt, and the sea filled the valley
as far as a point not much north of Assouan. Into this fiord ran
several rivers from the high ground east and west, bearing down with
them heaps of detritus, and forming small deltas like the plain of
Kom-Ombos. On the sea-bottom were laid down deposits of sand
and gravel, and then the land began to rise. Meantime the volcanic
movements of East Central Africa had shaped the country into its
present configuration, and the rivers which drained from the great
lakes and swamps of the south, and those which flowed down from
the high plateau on the east, combining their waters somewhere
about Khartoum, pushed their marvellous course northwards, and
began the creation of the fertile soil of Egypt. From this time onwards
the climatic conditions must have continued very much what they are
to-day. Changes, of course, there have been in the level of the land;
but the sea-valley had become a river-valley, and year by year the
annual flood increased the cultivable soil, and refreshed it with
moisture, just as it would be doing to-day if left untrammelled by the
devices of man.
Late in the history of the river-valley, but very early in the history
of humanity, this favoured strip of country became the home of men,
who doubtless cast their seed upon the slime left by the retreating
waters, and reaped their crops long before the dawn of history. It is
remarkable and characteristic of the conditions of the country that
tradition ascribes to the earliest King of Egypt, Menes, the first King
of the First Dynasty, the first attempts to regulate the flow of the river
—in other words, the first scheme of irrigation proper.
If it were possible to divert the river from its course, and effectually
to bar its way before it reached the boundaries of Egypt, what an
appalling catastrophe would follow—no mere disaster, but absolute
annihilation! On the coast lands of the Mediterranean a sparse
population might still eke out a miserable existence by storing the
scanty rainfall, but nowhere else. The very oases of the desert would
be dried up, and in a short time the shifting sands of the Sahara
would have overlaid the deposits in the river-valley, and buried out of
sight even the ruins of the past. The waters of the Nile are, and ever
have been, the sole giver of all life in Egypt.
Whoever finds himself in Cairo should lose no time in taking his
stand upon the bridge, and in reflecting upon the history of the water
that goes sliding and eddying beneath him, on the way to perform its
last duties among the cotton-fields of the delta. Some of it has been
travelling for three months from its sources beyond the Victoria
Nyanza, itself over 1,100 metres[1] above sea-level. From the
Victoria Nyanza it has passed down the Somerset Nile into the Albert
Nyanza, thence a five days’ journey to Lado, past Duffile and the
Fola Rapids. From Lado to Bor the fall is still rapid, but henceforward
as far as Khartoum, some 1,000 miles, the stream is on a very feeble
slope. Between Bor and the junction of the Ghazal River on the left
bank is the region of the sudd, floating masses of compressed
vegetation, which, if neglected entirely, block the course of the river.
Here, too, are the wide and desolate marshes, inhabited by myriads
of mosquitoes and that strange, melancholy bird, the whale-headed
stork (Balæniceps rex).
The Ghazal River contributes very little to the flow of the Nile,
owing to wide lagoons through which it passes, and which cause
great evaporation. The river then passes sharply to the right, and
sixty miles further on is joined by the Sobat from the eastern hills,
which in flood brings down a volume equal to that of the Nile, but
during summer contributes little or nothing. From the white sediment
brought down by the Sobat the White Nile derives its name and
colour. Hence it flows in a wide bed, a mile across on the average,
540 miles to its junction with the Blue Nile at Khartoum. Khartoum is
still 1,800 miles from the sea, and 390 metres above it. Two hundred
miles north of Khartoum, near to Berber, the Atbara River flows in,
and hence the Nile pursues its solitary way through the desert until,
after a circuitous bend round Dongola, it bursts through the rocky
defiles of Nubia, and emerges at Assouan into Egypt proper. Of the
distance between Khartoum and Assouan about 350 miles consist of
so-called cataracts, during which the total drop is 200 metres; about
750 miles are ordinary channel, with a total drop of nearly 100
metres.
Of all the affluents of the Nile, the Blue Nile (assisted by its
tributaries, the Rahad and the Dinder) and the Atbara have been of
infinitely the greatest importance to Egypt in the past. Not only do
their waters contribute the largest proportion of the annual flood, but
also down them comes the rich volcanic detritus swept from the
Abyssinian hills by the heavy summer rains, which composes the
red-brown silt so dear to the Egyptian cultivator. To understand the
system of irrigation in Egypt it is necessary to have a clear view of
the amount of water derived from the different sources at different
times of the year.
The great lakes and swamps of Uganda, acting as reservoirs,
prevent any great differences in the discharge of water above Lado.
At that place the low Nile discharge is about 500 cubic metres[2] per
second; but, in spite of the Ghazal River and the Sobat, so great is
the loss by diffusion in the marshes and by direct evaporation, that at
Khartoum the discharge is no more than 300 cubic metres per
second. At this time the Blue Nile is giving no more than 160 cubic
metres per second at Khartoum, and the Atbara is not running at all.
The loss between Khartoum and Assouan is about 50 cubic metres,
and consequently the amount of water passing Assouan in May in an
ordinary year is 410 cubic metres per second. This is the summer
supply of Egypt.
Meantime heavy rains have been falling about Lado and on the
Sobat. Towards April 15 the river begins to rise, the effect of which is
felt at Khartoum about May 20, and at Assouan about June 10. A
most curious phenomenon accompanies this preliminary increase—
the appearance of the ‘green’ water. It used to be thought that this
‘green’ water proceeded from the sudd region. During the previous
months the swamps in that country have been lying isolated and
stagnant under the burning tropical sun; their waters have become
polluted with decaying vegetable matter. When once more the rising
river overtops its banks, this fœtid water was supposed to be swept
out into the stream, and finally make its appearance in Egypt. But a
closer examination of the facts, which has only been possible since
the Soudan was re-opened, has caused this view to be abandoned.
The ‘green water’ is caused by the presence of an innumerable
number of microscopic algæ, which give it a very offensive taste and
smell. So far as can be ascertained, their origin is in the tributaries of
the Sobat above Nasser. The rains in April carry them out into the
White Nile, and thence they pass down to Nubia and Egypt. Under a
hot sun and in clear water they increase with amazing rapidity, and
sometimes they form a column 250 to 500 miles long. These weeds
go on growing, drying, and decaying, until the arrival of the turbid
flood-water, which at once puts an end to the whole process, as they
cannot survive except in clear water.
Horrible as the ‘green’ water is, its appearance is hailed with
delight by the Egyptian, for he knows that it is the forerunner of the
rushing waters of the real flood-time, and the first sign of the coming
close of the water-famine. By September 1 the Nile at Lado has
reached its maximum of 1,600 cubic metres. In the valley of the
Sobat the rains last till November, with the result that by September
15 or 20 the White Nile at Khartoum has attained its maximum
discharge of 4,500 cubic metres per second.
Meanwhile great things have been happening on the Blue Nile
and the Atbara. About July 5 the Blue Nile begins to rise, and the
flood comes down with considerable rapidity till it reaches its
maximum of 5,500 cubic metres per second on August 25. The
famous ‘red’ water reaches Assouan on July 15, and is seen ten
days later at Cairo. The flood on the Atbara would begin at nearly the
same time as on the Blue Nile, but for the fact that it spends a month
in saturating its own dry bed and the adjoining country. Once it
begins, however, about July 5, it comes very rapidly, and about
August 20 reaches its maximum, which is usually some 3,400 cubic
metres per second, but occasionally amounts to as much as 4,900.
If these three contributors, the White Nile, the Blue Nile, and the
Atbara, all reached their maximum at the same time, the result in an
ordinary year would be a discharge at Assouan of some 13,000 to
14,000 cubic metres per second, and in occasional years a very
great deal more. But this is not the case. In an ordinary year the Nile
is at its lowest at Assouan at the end of May, discharging no more
than 410 cubic metres per second. After the arrival of the ‘green’
water it rises slowly till July 20. By that time the ‘red’ water is fairly on
the move, and the rise goes on with increased rapidity till the
maximum is reached, on September 5, of 10,000 cubic metres. But
both date and amount are liable to variation. If the White Nile flood is
a weak one, and the Atbara early, the maximum may be reached a
day or two earlier; but if the White Nile is very strong it will not be
attained until September 20. A late maximum, in other words, means
a good supply of water in the White Nile, and as the White Nile is the
principal source of supply after the flood is over, this fact is of
inestimable importance to Egypt. But occasionally, as in 1878, this is
carried to excess. In that year the White Nile flood was very late and
very high. The maximum was not reached till September 30, when
13,200 cubic metres per second were passing Assouan, with very
disastrous results in Egypt. All through the following summer the
supply was very good, and at its lowest, in May, was more than three
times as great as the average.[3]
Curiously enough, the preceding year offered a startling contrast.
It was the lowest Nile on record. The maximum was reached on
August 20, and was some 3,500 cubic metres below the average,
and in the following May the discharge at Assouan fell to 230 cubic
metres per second, as against the average 410.
By the end of October the Atbara has usually disappeared
altogether, and the Blue Nile falls very quickly after the middle of
September. The White Nile, however, owing to the regulating effect
of its natural reservoirs and the slackness of its current, is very much
more deliberate in its fall, and the results at Assouan are as follows
in a normal year: By the end of September the discharge has fallen
to 8,000 cubic metres per second; end of October to 5,000; end of
November to 3,000; end of December to 2,000; end of January to
1,500; end of March to 650; and end of May to 410.
In other countries the year is divided into seasons, reckoned
according to the position of the sun and the temperature, or
according to the rainfall. In Egypt the state of the all-important river is
the principal factor in determining the seasons. These are, first, the
months of the inundation, or Nili, August to November; second, the
winter, or Shitwi, December to March; and, third, the summer, or
Sefi, April to July, when the river is at its lowest. Nowhere else do the
actual seasons correspond with the nominal in a manner so regular
and unfailing. But, of course, within these limits there is a great
variation in the amounts of both the maximum and the minimum of
the volume of the Nile, and the dates at which they occur from year
to year. During the twenty-six years 1873-1898 the maximum flood at
Assouan varied from the exceptional height of 9·15 metres above
zero on the gauge to the equally exceptional 6·40 metres. And the
dates on which these maxima were attained varied from October 1 in
the first case to August 20 in the other. The dates on which the
volume of water passing through reached its minimum varied from
May 8 to June 24; while the worst lowest on record was ·71 metre
below zero, and the best was 1·88 metres above it. (Zero, it should
be explained, is the lowest level which the river would touch in an
average year.)
These figures are the result of the free and unimpeded flow of the
Nile. To us, with our wider field of observation, with our knowledge of
the sources of the Nile, and preciser information as to the conditions
prevailing in those distant countries, the behaviour of the river
seems, after all, but the resultant of many natural causes, and
capable of prediction, and even regulation. But to those who, living in
a country where rain was practically unknown, knew nothing of the
tropical lakes or the rain-shrouded hills of Abyssinia, and who merely
saw the great river issuing from the burning deserts of the south in
flood at the very time when other rivers were parched and dried, how
marvellous it must have seemed, and how inexplicable must have
appeared those occasional variations, threatening destruction, on
the one hand by excessive inundation, and on the other by famine
and drought! Few floods in the history of Egypt can have been higher
than that of 1878, and few lower than that of 1877, when 1,000,000
acres were left without water. But several great famines have been
recorded in the past. Perhaps the worst of these began in A.D. 1064.
A succession of low Niles took place, lasting for seven years, like the
seven lean kine of Pharaoh’s dream. Terrible results followed. Even
human flesh was eaten, and the Caliph’s family had to flee to Syria.
Similar disasters occurred in A.D. 1199.
Such extraordinary catastrophes are rare, but their possibility is
always present to the minds of those responsible for the government
and welfare of Egypt. We shall see what steps have been taken to
guard against them, and first we shall examine the different systems
of irrigation which have prevailed, and the nature of the services
which the water, whose variations we have described, is made to
perform before it finally reaches the sea.
CHAPTER II
BASIN IRRIGATION
There are two kinds of irrigation in Egypt—basin and perennial

irrigation. Basin irrigation is the ancient and historical method of the
country. Tradition ascribes its invention to the first King of Egypt, and
it is obviously designed to take full advantage of the annual flood.
Practically the same as it was 7,000 years ago, it may be seen in
Upper Egypt to-day.
The cultivable land from Assouan to the Delta is, with the
exception of the Fayoum, that altogether remarkable province, a
narrow strip of country, varying in breadth from a few miles to
nothing at all, sometimes on both sides of the river, sometimes only
on one. Being of deltaic formation, the land is highest near the river,
and slopes away towards the desert. As the river flows from south to
north, there is, of course, also a general slope of the country in the
same direction. Earthen dykes are run at right angles to the river as
far as the desert, a dyke parallel to the river and close to its bank
connects them, and so a basin is formed, enclosed on the fourth side
by the desert. Thus the land is arranged in a series of terraces.
Usually these basins are arranged in a series, one basin draining
into its neighbour, the last of the series discharging back again into
the Nile. Sometimes a second dyke, parallel to the river, divides the
lower land near the desert from the higher; sometimes the
arrangement is still further complicated by other dykes, making
enclosures within the area of the original basin.
The object of the basins is to regulate the supply of the flood-
water. Each series of basins has special feeder canals to lead into
them. These are shallow, and have their bed about halfway between
the high and low level of the Nile. They are therefore dry in the winter
and summer, and only run during the flood. The heads of these
canals, where they take off from the Nile, remain closed by dams or
by masonry regulators till the silt-bearing flood is coming down in
sufficient strength. Then about August 10 or 12 the canals are
opened and the basins filled. The lowest basins in each series are
filled first, then the next lowest, and so on. In a low flood, as in 1877,
there is not enough muddy water to go round, and the upper basins
get no water at all; such lands are called ‘sharaki,’ and are exempt
from taxation. For forty days the flood-water stands on the land,
thoroughly soaking it and washing it, and at the same time
depositing its fertilizing silt. At the end of that time, through the
escape at the lower end of the series, the water is discharged back
again into the Nile. But if the flood is a very high one or very slow in
abating, the date at which the water can be discharged and the
basins dried has to be postponed. Fortunately, this seldom happens;
but when it does it has a doubly bad effect. The oversoaking is said
to engender worms, and also the ripening of the crops is postponed
to an unfavourable season of the year.
Against this particular evil there is no remedy, but since the British
occupation a great deal has been done to improve the system of
basin irrigation, and prevent a large amount of sharaki even in years
of low Nile. These measures consist in arrangements for distributing
the ‘red’ water more evenly over the whole system, and not allowing
the lower basins only to receive the full benefit, while the higher
merely receive ‘white’ water—i.e., water which has already deposited
its silt. Further, since any water is better than none, the systems of
basins have been so managed, where possible, that the water from
an upper system can be drained into a lower one, and thus make up
deficiencies, though with water of an inferior quality. More attention
has also been paid to the angle at which the feeder canals take off
from the Nile, and the slope on which they are laid, so as to provide
as much ‘red’ water as possible, while diminishing the amount of
silting up. The result of this work is seen in the diminution of the
sharaki lands year by year. In 1877 these amounted to nearly
1,000,000 acres, a loss of £1,000,000 in land-tax. During the next
ten years the average was 45,000 acres, an annual loss of some
£40,000. In 1888 the loss was £300,000, and the Egyptian
Government expended £800,000 in remedial works, which have had
an extraordinary effect. In 1899, when the Nile was exceptionally

(Download PDF) Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(Download PDF) Azure SQL Hyperscale Revealed High Performance Scalable Solutions For Critical Data Workloads 1St Edition Zoran Barac Full Chapter PDF

Uploaded by

Copyright:

Available Formats

Azure SQL Hyperscale Revealed:

High-performance Scalable Solutions

Azure SQL Hyperscale Revealed: High-performance

Developing Cloud-Native Solutions with Microsoft Azure

Modern Data Architecture on Azure: Design Data-centric

Practical Graph Structures in SQL Server and Azure SQL:

Pro SQL Server 2022 Wait Statistics: A Practical Guide

Pro SQL Server 2022 Wait Statistics: A Practical Guide

Beginning Azure Functions: Building Scalable and

Beginning Azure Functions: Building Scalable and

ISBN-13 (pbk): 978-1-4842-9224-2 ISBN-13 (electronic): 978-1-4842-9225-9

Copyright © 2023 by Zoran Barać and Daniel Scott-Raynsford

About the Technical Reviewers����������������������������������������������������������������������������� xiii

Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations����������� 37

Part II: Planning and Deployment����������������������������������������������������������������� 75

Chapter 4: Deploying a Highly Available Hyperscale Database

Chapter 5: Administering a Hyperscale Database in a Virtual Network

Chapter 7: Enabling Geo-replication for Disaster Recovery��������������������������������� 187

Chapter 8: Configuring Security Features and Enabling Diagnostic

Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell���������������������� 213

Chapter 12: Testing Hyperscale Database Performance Against Other

Part III: Operation and Management����������������������������������������������������������� 339

Chapter 14: Backup, Restore, and Disaster Recovery������������������������������������������ 361

Chapter 15: Security and Updating����������������������������������������������������������������������� 381

Chapter 16: Managing Costs�������������������������������������������������������������������������������� 399

Part IV: Migration��������������������������������������������������������������������������������������� 407

Chapter 18: Migrating to Hyperscale�������������������������������������������������������������������� 419

Chapter 19: Reverse Migrating Away from Hyperscale���������������������������������������� 449

Chapter 20: Conclusion����������������������������������������������������������������������������������������� 459

Daniel Scott-Raynsford is a partner technology strategist

Vitor Fava has earned the title of Most Valuable Professional

At its core, Hyperscale helps us address these changing requirements, without

The Basics of Azure SQL

• As infrastructure as a service (IaaS) using SQL Server on Azure VMs

Figure 1-1. Continuum of cost and administration of different hosting models

Azure SQL Platform as a Service

• Azure SQL Database

• Azure SQL Managed Instance

Table 1-1. Azure SQL PaaS Deployment Options

Purchasing Models and Service Tiers

• Basic: Use for less demanding workloads: up to 5 DTU, up to 2GB

• Standard: Use for workloads with typical requirements: up to 3000

• Premium: Use for I/O-intensive workloads: up to 4000 DTUs, up to

The vCore purchasing model represents a choice of specific virtual hardware

• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore,

• Azure SQL DB Serverless: 0.5–80 vCores, up to 240GB memory,

• Azure SQL DB: 2–128 vCores, up to 625GB memory, and up to

• Azure SQL MI: 4–80 vCores, Standard-series 5.1GB RAM/vCore

• Standard-series (Gen5): 2–80 vCores, up to 415GB memory, and

• Premium-series: 2–128 vCores, up to 625GB memory, and up to

• Premium-series memory-optimized: 2–128 vCores, up to 830GB

• DC-series (enables confidential computing): 2–8 vCores, up to

Availability Models and Redundancy

• Standard: Separates compute and storage tiers. It relies on the

• Premium: Like the Always On availability option for VMs. It relies on

• Local redundancy: All Azure SQL PaaS deployments offer local

• Zone redundancy: This replicates a database across multiple

• Geo-redundancy: There are multiple ways to achieve geo-redundancy

Tip Zone-redundant configuration is available only for Azure SQL Database

• Standard availability model: DTU purchasing model Basic and

• Premium availability model: DTU purchasing model Premium

 tandard Availability Model: Locally

About the Technical Reviewers�� xiii

Chapter 2: Azure SQL Hyperscale Architecture Concepts and Foundations�� 37

Part II: Planning and Deployment�� 75

Chapter 4: Deploying a Highly Available Hyperscale Database

Chapter 5: Administering a Hyperscale Database in a Virtual Network

Chapter 7: Enabling Geo-replication for Disaster Recovery�� 187

Chapter 8: Configuring Security Features and Enabling Diagnostic

Chapter 9: Deploying Azure SQL DB Hyperscale Using PowerShell�� 213

Chapter 12: Testing Hyperscale Database Performance Against Other

Part III: Operation and Management�� 339

Chapter 14: Backup, Restore, and Disaster Recovery�� 361

Chapter 15: Security and Updating�� 381

Chapter 16: Managing Costs�� 399

Part IV: Migration�� 407

Chapter 18: Migrating to Hyperscale�� 419

Chapter 19: Reverse Migrating Away from Hyperscale�� 449

Chapter 20: Conclusion�� 459

The Basics of Azure SQL

Azure SQL Platform as a Service

Purchasing Models and Service Tiers

Availability Models and Redundancy

tandard Availability Model: Locally

General Purpose Service Tier: Zone-Redundant Availability

remium and Business Critical Service Tier: Locally

remium and Business Critical Service Tier:

rotecting Against Regional Outages Using Failover

The Hyperscale Service Tier

Hyperscale Architecture Overview

Deploying Your First Hyperscale Database