Если бы у меня была возможность, я бы сделал эти 4 улучшения для Azure SQL Database. Они не имеют особого порядка, на самом деле я мог бы предложить около 10 функций / улучшений, которые мне бы хотелось увидеть, но я думаю, что 4 будет достаточно. Некоторые из них более реалистичны, чем другие, я уверен, что в отношении некоторых из них  у меня больше шансов получить тигра в качестве домашнего животного.

Azure SQL Analytics

Это было бы здорово, если бы оно было больше интегрировано в blade-сервер в портале. Это, вероятно, довольно легко сделать, и это улучшит работу пользователя. Сейчас это может быть немного запутанным. Вам необходимо включить диагностические настройки в базе данных / адаптивном пуле, а затем перейти и создать рабочее пространство для анализа журналов. Как легко было бы, если бы мы могли все это сделать с помощью кнопки на основном блейд-сервере базы данных? Что-то вроде этого:

По умолчанию восстанавливать файл .BAK

Мне бы очень понравилась эта возможность, и это избавило бы меня от использования BACPAC. Представьте, что у вас есть возможность сделать копию только полной резервной копии прямо в хранилище Azure, а затем войти в систему через SSMS и написать несколько TSQL для восстановления? Проблема с BACPAC заключается в том, что могут возникать трудности при выполнении на занятых системах, и это на самом деле не настоящие резервные копии.

Встроенное автоматическое увеличение и уменьшение масштабирования

Это опять же то, что вы можете сделать через PowerShell и запустить его через рабочую книгу, код не слишком сложный, но эта функция должна быть открыта через портал. Что-то вроде того, что Microsoft уже делает для виртуальных машин. Например, автомасштабирование на основе показателя производительности, то есть, если мой CPU для моей базы данных SQL (уже захвачен Azure в любом случае)> 90% использования позволяет масштабировать до более высокого уровня обслуживания. Или, возможно, основываясь на времени? Я знаю, что в 2 часа ночи у нас небольшое количество пользователей, поэтому давайте уменьшим масштаб. Очевидно, нам нужно будет внести изменения в приложения, чтобы справиться с такими изменениями, потому что это может означать, что соединения будут отброшены, возможно, политика повтора может работать здесь. Какой шаг будет далее? Возможно, что-то вроде услуги автоматического масштабирования DynamoDB от Amazon, где он может динамически настраивать пропускную способность от нашего имени в ответ на фактические шаблоны трафика.

Выполнить команду USE

Чтобы иметь возможность выполнять что-то вроде:

USE [AWSDB]
GO
SELECT [SalesOrderID]
     ,[RevisionNumber]
     ,[OrderDate]
     ,[DueDate]
     ,[ShipDate]
FROM [SalesLT].[SalesOrderHeader]
GO
USE [FastDB]
GO
SELECT * FROM [dbo].[BuildVersion]

Который всегда возвращается -

Msg 40508, уровень 16, состояние 1, строка 11 Утверждение USE не поддерживается для переключения между базами данных. Используйте новое соединение для подключения к другой базе данных. Msg 208, уровень 16, состояние 1, строка 13.

А что бы вы изменили или добавили?

No Comments