Когда я впервые узнал о том, что SQL Server 2022 будет поддерживать мгновенную инициализацию файлов журнала транзакций, я был заинтригован. Когда позже выяснилось, что это относится только к   автоматическому приращению и только с размером не больше 64 МБ, интрига несколько потеряла свой «блеск». Из-за этих ограничений я скептически отнесся к тому, что новая стратегия сможет заменить сложившуюся практику автоматического увеличения файлов журналов на 1 ГБ — по крайней мере, с тех пор, как SSD и другие современные хранилища получили достаточное распространение.

Но поигравшись с этим новшеством, я проникся.

Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…

Резервное копирование и восстановление из объектного хранилища S3 — это новая функция, появившаяся с выпуском SQL Server 2022. Резервное копирование или восстановление можно делать в S3, расположенное локально или в облаке.

Microsoft SQL Server 2022 представляет новую возможность запрашивать данные непосредственно из источников, осуществлять виртуализацию данных, и использовать интерфейсы REST API. Это делает работу с данными ещё более лёгкой и гибкой, за счёт увеличения числа поддерживаемых коннекторов и форматов файлов. Поддерживаются форматы: CSV, Parquet и Deltafiles, хранящиеся в любом объектном хранилище, совместимом со службой хранения S3, как локально, так и в облаке. И наконец, SQL Server 2022 теперь может использовать операции Create External Table as Select (CETAS) в OPENROWSET, вместе с такими командами как Create External Table (CET) совместно со всеми возможностями T-SQL. Всё это делает SQL Server 2022 мощным центром управления данными.

В SQL Server 2022 мы представили новую функцию, называемую: «Degree of parallelism feedback» (обратная связь для DOP). Эта функция отслеживает запросы с параллелизмом и определяет, может ли запрос работать лучше при меньшей степени параллелизма, чем используется в момент исполнения. Например, вполне возможно, что 16 потоков будут работать лучше двадцати, если в этих потоках много ожиданий процессора. Будет выполнена пробная проверка новой степени параллелизма и либо принято решение, что это хорошее изменение, и далее будут применяться 16 потоков, либо так и останется DOP = 20 потоков. Если новая степень параллелизма покажет лучшие оценки для запроса, то это значение будет сохранено в «Query Store» (хранилище запросов) и будет соответствующим образом применяться к запросу при следующем исполнении.

Оценка кардинальности «Cardinality estimation» (CE) — это процесс, используемый оптимизатором запросов для оценки количества строк, возвращаемых запросом или частью запроса. Эти оценки основаны на двух базовых вещах: статистике данных и наборе допущений (assumptions), известных как модель. Модель определяет, как мы интерпретируем статистику и данные, поступающие из разных частей выражения, поэтому для любого заданного набора статистических данных разные модели приведут к разным оценкам кардинальности.

До SQL Server 2022 у CE могла быть только одна модель. Набор используемых допущений был встроен в код сервера, поэтому какая бы модель ни была выбрана, она использовалась для всех таких запросов. Однако, мы знаем что не все запросы и рабочие нагрузки работают одинаково хорошо в рамках одной единственной модели. Для некоторых запросов модель будет работать хорошо, а для других лучше подходит другая модель. В SQL Server 2022 появилась возможность адаптировать модель с помощью CE Feedback (оценка кардинальности с обратной связью), приспосабливая план запроса к конкретному запросу.

CE всегда исходила из трех основных допущений, составляющих модель: независимость (или частичная независимость), однородность и контейнирование. Эти три предположения определяют как мы интерпретируем гистограммы, как мы объединяем данные, реализуя соединения, и как поступаем при наличии нескольких предикатов. В этой статье будут рассмотрены подробно возможные варианты моделей и их влияние на запросы.

Мы рады сообщить, что в SQL Server 2022 достигнуты серьёзные успехи в ускорении восстановления базы данных (ADR). Это еще больше повышает доступность и масштабируемость баз данных, в первую очередь направлено на облегчение очистки и управления хранилищем версий - Persistent Version Store (PVS).

В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как OpenVPN и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера двух видов для всего этого.

Многим читателям, однако, ручная настройка показалась сложной и неудобной - хотелось иметь понятный легко устанавливаемый графический интерфейс без необходимости ручного редактирования конфигов и вероятности допустить ошибки, а еще мы не поговорили про механизм "подписок", позволяющих клиентам автоматически подключать список новых серверов с настройками подключений.

Поэтому сегодня мы поговорим об установке и использовании графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

В SQL Server 2022 добавилась новая функция для статистики — AUTO_DROP. В этой статье мы расскажем, что она даёт и как её включать и выключать. Также будут представлены несколько примеров и показаны некоторые распространенные ошибки и способы их решения. Для демонстрационных примеров в этой статье мы будем использовать следующее:

Данные временных рядов — это набор значений, упорядоченных так, как они появляются и поступают для обработки. В отличие от транзакционных данных SQL Server, которые не зависят от времени и могут часто обновляться, данные временных рядов обычно записываются один раз и, если обновляются, то крайне редко.

Вот несколько примеров данных временных рядов: цены на акции, телеметрия от датчиков, счётчики производительности SQL Server (например, утилизация ЦПУ, памяти, устройств ввода‑вывода и сети).

Данные временных рядов часто используются для сравнений в истории наблюдений, обнаружения аномалий и уведомления о достижении заданного порога, прогнозного анализа и составления отчетов, где время является осью значений при просмотре или анализе данных.

В серии предыдущих статей я описывал, почему повсеместно используемые VPN- и прокси-протоколы такие как Wireguard и L2TP очень уязвимы к выявлению и могут быть легко заблокированы цензорами при желании, обозревал существующие гораздо более надежные протоколы обхода блокировок, клиенты для них, а также описывал настройку сервера для всего этого.

Но кое о чем мы не поговорили. Во второй статье я вскользь упомянул самую передовую и недетектируемую технологию обхода блокировок под названием XTLS-Reality, и пришло время рассказать о ней поподробнее, а именно - как настроить клиент и сервер для нее.

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

Предыдущие статьи серии:

Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria и все-все-все
Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие

С протоколами разобрались, с клиентами разобрались, теперь наконец-то настало время рассказать о том, как же настроить свой личный прокси-сервер с современными протоколами для обхода блокировок. Мы будем настраивать сервер на базе XRay (который является форком известного V2Ray, и еще я немного упомяну Sing-Box) с протоколами Shadowsocks-2022 и VLESS с транспортом XTLS-Vision и фейковым веб-сайтом для защиты от выявления. И в качестве запасного варианта на том же сервере мы настроим fallback на VLESS+Websockets, чтобы была возможность работать через CDN типа Cloudflare, если вдруг IP-адрес вашего сервера попадет под блокировку. В конце я приведу настройки десктопных и мобильных клиентов для подключения ко всему этому.

В предыдущей статье “Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria и все-все-все” я рассказывал про прокси-протоколы. Теперь настало время рассказать про клиенты: консольные, GUI для десктопа и для мобильных платформ. 

Надеюсь, что эта статья вам окажется полезной, потому что, как выяснилось, найти хороший клиент даже для тех же V2Ray/XRay в наше время не так-то просто. Потому что большая часть того, что находится при поиске в интернете “в лоб” и даже в списках типа Awesome V2Ray - или уже неподдерживаемое, или довольно кривое, или не умеющее в актуальные версии и фичи (например, XTLS и uTLS), а самые жемчужины прячутся где-нибудь в глубинах Github’а и сторов.

В этой статье мы обсудим, как устроен агрегат WITH ROLLUP. Использование предложения WITH ROLLUP позволяет выполнить несколько «уровней» агрегации в одном операторе. Например, предположим, что у нас есть некие данные о продажах (это те же данные, которые я использовал в серии статей об операторе PIVOT).

Три месяца назад здесь на Хабре была опубликована статья “Интернет-цензура и обход блокировок: не время расслабляться”, в которой простыми примерами показывалось, что практически все популярные у нас для обхода блокировок VPN- и прокси-протоколы, такие как Wireguard, L2TP/IPSec, и даже SoftEther VPN, SSTP и туннель-через-SSH, могут быть довольно легко детектированы цензорами и заблокированы при должном желании. На фоне слухов о том, что Роскомнадзор активно обменивается опытом блокировок с коллегами из Китая и блокировках популярных VPN-сервисов, у многих людей стали возникать вопросы, что же делать и какие технологии использовать для получения надежного нефильтрованного доступа в глобальный интернет.

Мировым лидером в области интернет-цензуры является Китай, поэтому имеет смысл обратить на технологии, которые разработали энтузиасты из Китая и других стран для борьбы с GFW (“великим китайским файрволом”). Правда, для неподготовленного пользователя это может оказаться нетривиальной задачей: существует огромное количество программ и протоколов с похожими названиями и с разными не всегда совместимыми между собой версиями, огромное количество опций, плагинов, серверов и клиентов для них, хоть какая-то нормальная документация существует нередко только на китайском языке, на английском - куцая и устаревшая, а на русском ее нет вообще.

Поэтому сейчас мы попробуем разобраться, что же это все такое и как это использовать и не сойти с ума.

Рассмотрим следующий пример:

CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)

Теперь предположим, что мы выполним обновление:

UPDATE T SET A = 1 – A

Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:

  _{|--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
       |--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
            |--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
                 |--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
                      |--Top(ROWCOUNT est 0)
                           |--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))}

Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.

_{Оперативно узнавать о новостях MS SQL Server можно в телеграмм-канале: MS SQL Server - дело тонкое...}

Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.

В предыдущей статье было показано как SQL Server выполняет изменения в некластерных индексах, но пока только в тех случаях, когда данные в индексе действительно изменяются. В примере из прошлой статьи использовался простой оператор UPDATE, который порождает построчный или «узкий» план запроса. В этой статье будет показано как оптимизируется план с изменениями данных с индексами в «широком» плане запроса.

Планы запросов на вставку, изменение и удаление состоят из двух частей. Первая часть называется курсор чтения, и она определят то множество строк, которое необходимо вставить, изменить или удалить. Вторая часть называется курсор записи, и в этой части непосредственно происходит вставка, изменение или удаление данных. Давайте рассмотрим простой пример:

Disclaimer: практически всё описанное в статье, не является чем-то принципиально новым или инновационным - оно давно известно и придумано, используется в разных странах мира, реализовано в коде и описано в научных и технических публикациях, поэтому никакого ящика Пандоры я не открываю.

Нередко на Хабре в темах, посвященных блокировкам ресурсов встречаются забавные заявления, вида "Я настроил TLS-VPN, теперь будут смотреть что хочу и цензоры мой VPN не заблокируют", "Я использую SSH туннель, значит все ок, не забанят же они SSH целиком", и подобное. Что ж, давайте проанализируем опыт других стран и подумаем, как же оно может быть на самом деле.