Так вышло
Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.
Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.
По материалам статьи Esther Xin «Prevent SQL Server Dump Generation in Hot Cases: Common Ways & Scenarios»
14 ноября 2021г.
В этой статье будут описаны способы предотвращения создания дампа SQL Server для наиболее часто встречающихся видов исключений. В промышленной среде это позволит продержаться до решения проблемы, в случае, когда генерация дампов сильно мешает нормальной работе. Подразумевается, что у вас уже есть файл дампа, пригодный для расследования RCA. Также, вы должны быть уверены, что причиной создания дампов является одно и то же исключение, о чём говорит одинаковый стек вызовов для потока, приведшего к дампу.
В продуктиве, особенно когда SQL Server является частью кластера (SQL AG или FCI), в качестве быстрого решения для защиты от сбоев, вызванных процессом генерации дампа, поддержка Майкрософт может предложить рассмотреть возможность отключения процесса создания дампа.
Главной опасностью того, что файл дампа не будет генерироваться после того, как произойдёт исключение, является невозможность дальнейшего поиска и устранения проблем на основании содержащейся в дампе информации. Кроме того, само отключение возможности создания дампа не может избавить от возникновения исключения в процессе SQL Server. Применяя этот метод, будьте осторожны и учитывайте возможные риски, связанные с тем, что отсутствие дампов может ввести в заблуждение при оценке состояния сервера. Обязательно согласуйте отключение дампов со всеми заинтересованными сторонами, прежде чем вносить какие-либо изменения.
Конечно, увеличение тайм-аута проверки статуса сервера и тайм-аута проверки работоспособности может быть альтернативным вариантом реакции на череду дампов, но в типичном продуктиве в случае аварии, когда требуется быстрый отклик и быстрая отработка отказа, такой вариант не подходит (нежелательно ждать генерации дампа перед отработкой отказа или длительное создание дампа само может стать причиной отработки отказа).
Ниже показаны несколько флагов трассировки, которые позволяют отключить создание дампа в наиболее часто встречающихся случаях. В других случаях, следует обратиться к документации Майкрософт, которая описывает соответствующие флаги трассировки и поведение сервера после их включения.
По материалам статьи Craig Freedman: Query Failure with Read Uncommitted
В предыдущих статьях были рассмотрены практически все уровни изоляции, за исключением Read Uncommitted или NOLOCK. Эта статья завершает серию обсуждением того, что может приключиться, если читать данные ещё не зафиксированных транзакций. О вреде NOLOCK написано уже немало. Например, вы могли об этом почитать у Любора Коллара (Lubor Kollar) из «SQL Server Development Customer Advisory Team» и в (ныне уже недоступном) блоге Тони Роджерсона (Tony Rogerson).
В дополнение к многочисленным аргументам, ниже будет продемонстрирована еще одна опасность NOLOCK. Начнём с создания двух таблиц:
Опубликовано 23 марта 2019 г., впервые опубликовано в MSDN 12 июня 2007 г.
Так уж случилось, что я пишу код для разных IoT-железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основным фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее.
Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится.
Как и любой другой инструмент, POSIX-сигналы имеют свои правила, как их использовать грамотно, надежно и безопасно. Они испокон веков описаны в самом стандарте POSIX, в стандартах языков программирования, в manpages, однако и по сей день я нередко встречаю связанные с этим грубые ошибки даже в коде опытных разработчиков, что в коммерческих проектах, что в открытых. Поэтому давайте поговорим о важном еще раз.
Шел апрель 2020 года, ковидная пандемия набирала обороты. Местные власти объявили "карантин", и от скуки сидения дома в один из дней мне пришла в голову мысль разобрать завалы хлама в старой квартире. В одной из коробок мне попался ноунеймовый USB DVB-тюнер на чипе RTL2832U с Алиэкспресса, и тут я призадумался. Вспомнилось, что много-много лет назад я игрался с ним и в эфире можно было услышать много интересного. "А почему бы не поиграться еще раз?" — возникла в голове мысль, которая и положила начало этой истории.
По материалам статьи Craig Freedman: Read Committed and Bookmark LookupВ предыдущих двух статьях мы обсуждали сценарии, при которых SQL Server продолжает удерживать блокировки Read Committed до конца исполнения оператора. Он это делает вместо того, чтобы снимать блокировку сразу после завершения работы со строкой. Один сценарий возможен при обновлении, а второй при работе с большими объектами. В этой статье (последней из цикла статей по блокировкам с Read Committed) будет рассмотрен сценарий использования в плане запроса оператора Bookmark Lookup, когда SQL Server также удерживает блокировки Read Committed дольше чем этого можно было бы ожидать.
Как легко догадаться после прочтения предыдущих статей, этот сценарий возникает, когда в плане запроса между операторами поиска по некластеризованному индексу и поиска закладок находится блокирующий оператор. В основном это случается в трёх случаях.
В наше время никого не удивишь, когда программа, написанная на скриптовом языке, вызывает нативный код, например, когда необходима максимальная производительность, обращение к каким-то внешним библиотекам или специфические системные вызовы. Точно так же, никого не удивишь, когда в программу на компилируемом языке встраивают интепретатор скриптового языка, например, для расширения функционала или возможности автоматизации действий пользователя. Но сегодня речь пойдет не о том, сегодня все будет немного более упорото.
Мы занимались разработкой... скажем так, системы отображения интерактивного контента для рынка одной азиатской страны. Пользователь имел "умное устройство", например, ТВ-приставку или смарт-телевизор, а "интерактивный контент" представлял собой по сути дела html/js/css-приложение, которое прилетало на устройство с трансляции или из интернета и отображалось в прозрачном окне поверх видео. В качестве веб-движка использовался модифицированный Blink из гугловского Chrome.
И вот, в один прекрасный день после какого-то из обновлений, один наш партнер (читай "поставщик контента") обратился к нам с проблемой: что-то не работает.
В моей последней статье было показано, что SQL Server при исполнении оператора UPDATE откладывает фиксацию блокировки до конца чтения (вместо снятия блокировок со строк сразу после их освобождения). Как там отмечалось, это делается для того, чтобы между просмотром или поиском строк для предстоящего изменения не допустить другие изменения. В этой статье будет рассмотрен аналогичный алгоритм при работе с большими объектами.
Давайте понаблюдаем за этим поведением. Начните с создания следующей таблицы:
Обычно, когда SQL Server прогоняет данные через блокирующий оператор, например, это может быть сортировка, он делает промежуточную материализацию этих данных. После того, как SQL Server сделает такую копию, нет необходимости в дальнейшем блокировании исходных строк или источника данных. Однако, поскольку большие объекты (например, varchar (max)) могут занимать до 2 Гбайт, делать копии больших объектов как правило непрактично. Взамен, когда это возможно, SQL Server использует указатели на данные вместо того, чтобы материализовать копию данных. Для гарантии, что указатели остаются актуальными, SQL Server не снимает блокировку строк, содержащих большие объекты, до завершения инструкции.
В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф.
В своей документации, Майкрософт обращает наше внимание на то, что не стоит выполнять обслуживание индексов, не убедившись, что это принесёт пользу. Вот цитата:
«Чтобы избежать ненужного использования ресурсов, что может негативно влиять на рабочие нагрузки запросов, корпорация Майкрософт рекомендует не применять обслуживание индекса без предварительной оценки. Следует опытным путем оценить повышение производительности от обслуживания индексов для каждой рабочей нагрузки, используя рекомендуемую стратегию, и сопоставить его с затратами ресурсов и влиянием на рабочую нагрузку, которые потребуются для достижения этих преимуществ.»
В том же документе рассматриваются причины повышения производительности запросов после обслуживания индексов и делается замечание, что не всегда это связано с дефрагментацией, бывают и иные причины. Вот ещё одна цитата:
Эти невыдуманные истории... хотя ладно, давайте на всякий случай считать что они целиком и полностью выдуманные, а любые совпадения с реально существующими людьми, компаниями и явлениями совершенно случайны.
Так вот, эти истории произошли в одном небольшом провинциальном городе в начале-середине 2000-х годов. Что такое ИТ и интернет в начале 2000-х в провинции? Домашний десктоп с Pentium 2 и 64 мегабайтами ОЗУ – весьма неплохая машина. Pentium 3 и 128 Мб – уже очень даже мощная. Основная ОС для домашнего пользователя – Windows 98, а те, кто посмелее и поподкованее используют прекрасную Windows 2000, которая в отличие от старой NT4 повернута к пользователю лицом, а не чем-то еще, а в отличие от линейки 95/98/ME не падает в синий экран от неудачного щелчка мышкой.
Rust не имеет перегрузки функций: вы не можете определить две функции, которые имеют одно и то же имя. Компилятор выдаст сообщение, что у вас имеется двойное задание одного и того же определения, хотя бы они и содержали разные типы аргументов.
После нескольких попыток задача была успешно решена. Как — под катом.
Сериализация данных посредством serde. Недавно я писал Rust-код для работы со сторонним источником данных в TOML-формате. В других языках я бы подгрузил данные какой-либо TOML-библиотекой и прогнал бы по ним мою программу, однако я слышал про serde — библиотеку сериализации на Rust, так что я решил попробовать ее.
Подробности — под катом.
Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.
Где и как их уместно применять? Смотрите под катом.
Раньше в Rust были состояния типов, которые были удалены из языка еще до официального релиза первой версии. В этой статье я раскрою вам тайну: Rust поддерживает состояния типов.
Прошу под кат.
Давайте познакомимся с Rust, поработав над маленьким проектом! Мы покажем основные концепты Rust на реальном примере. Вы узнаете о let, match, методах, ассоциированных функциях, подключении сторонних библиотек и много о чем другом. Мы реализуем классическую задачу: игра “угадай-ка”.
В последнее время я долго думал над персистентными коллекциями и в особенности над тем, как они относятся к Rust. Хочу поделиться с вами своими наблюдениями.
О том, как устроены персистентные векторы, быстрее ли они традиционных коллекций — смотрите под катом.
Сообщество Rust в последнее время сконцентрировало много своих усилий на асинхронном вводе/выводе, реализованном в виде библиотеки Tokio. И это замечательно.
Многим из участников сообщества, тем, которые не работали с веб-серверами и связанными с этим вещами, не ясно, чего же мы хотим добиться. Когда эти вещи обсуждались во времена версии 1.0, я тоже имел смутное представление об этом, никогда прежде не работав с этим раньше.
Рассмотрим модели многопоточности на примере Rust и Go.
Я покажу вам, как написать небольшую программу, которая скачивает ленту(feed) в формате JSON, парсит и выводит список заметок на консоль в форматированном виде.
У нас все вылилось в очень лаконичный код. Как? Смотрите под катом.