#microsoft_sql_server — Public Fediverse posts

Как секционирование помогло оптимизировать базу 1С:ERP объёмом 16 ТБ и победить datetime2

На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу. Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей. Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали. Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

https://habr.com/ru/companies/gri/articles/1048434/

#1С #ERP #Microsoft_SQL_Server #Оптимизация_базы_данных #Секционирование #партиционирование #datetime2

Как секционирование помогло оптимизировать базу 1С:ERP объёмом 16 ТБ и победить datetime2

На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу. Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей. Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали. Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

https://habr.com/ru/companies/gri/articles/1048434/

#1С #ERP #Microsoft_SQL_Server #Оптимизация_базы_данных #Секционирование #партиционирование #datetime2

Как секционирование помогло оптимизировать базу 1С:ERP объёмом 16 ТБ и победить datetime2

На одном из проектов заказчика объём базы 1С:ERP достиг 16 ТБ, а регистр накопления «СебестоимостьТоваров» вырос до 4 ТБ и 2 млрд строк. При таких объёмах оптимизация перестала быть опцией и превратилась в обязательную задачу. Симптомы были типичными для системы, которая упёрлась в пределы физического хранения: запросы к себестоимости выполнялись десятки минут, расчёт себестоимости тормозил, а серверный диск работал на пределе возможностей. Были применены стандартные подходы к оптимизации: работа с индексами и статистикой, а также дефрагментация. Существенного эффекта они не дали. Для решения задачи использовалось секционирование (партиционирование) таблиц на уровне MS SQL Server. Но, как оказалось, у 1С и секционирования сложные отношения. Меня зовут Владимир Андрейков, я руководитель группы разработки в GRI. Эта статья — разбор практического кейса из проекта заказчика. Она будет полезна тем, кто работает с крупными внедрениями 1С:ERP и упирается в ограничения SQL Server при больших объёмах данных.

https://habr.com/ru/companies/gri/articles/1048434/

#1С #ERP #Microsoft_SQL_Server #Оптимизация_базы_данных #Секционирование #партиционирование #datetime2

[Перевод] Как C#‑строки тихо убивают ваши индексы SQL Server в Dapper

Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени. Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день. Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.

https://habr.com/ru/articles/1007740/

#c# #net #microsoft_sql_server #программирование #базы_данных

[Перевод] Как C#‑строки тихо убивают ваши индексы SQL Server в Dapper

Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени. Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день. Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.

https://habr.com/ru/articles/1007740/

#c# #net #microsoft_sql_server #программирование #базы_данных

[Перевод] Как C#‑строки тихо убивают ваши индексы SQL Server в Dapper

Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени. Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день. Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.

https://habr.com/ru/articles/1007740/

#c# #net #microsoft_sql_server #программирование #базы_данных

Неочевидный подход в секционировании таблиц: Ring Buffer Partitioning в MS SQL Server

Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею. В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.

https://habr.com/ru/articles/993626/

#Microsoft_SQL_Server #SQL #Базы_данных #Ring_Buffer_Partitioning

Неочевидный подход в секционировании таблиц: Ring Buffer Partitioning в MS SQL Server

Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею. В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.

https://habr.com/ru/articles/993626/

#Microsoft_SQL_Server #SQL #Базы_данных #Ring_Buffer_Partitioning

Неочевидный подход в секционировании таблиц: Ring Buffer Partitioning в MS SQL Server

Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею. В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.

https://habr.com/ru/articles/993626/

#Microsoft_SQL_Server #SQL #Базы_данных #Ring_Buffer_Partitioning

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

https://habr.com/ru/articles/980392/

#ETL #Apache_Flink #Apache_Kafka #MongoDB #PostgreSQL #MySQL #Oracle #Microsoft_SQL_Server #OLAP

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

https://habr.com/ru/articles/980392/

#ETL #Apache_Flink #Apache_Kafka #MongoDB #PostgreSQL #MySQL #Oracle #Microsoft_SQL_Server #OLAP

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

https://habr.com/ru/articles/980392/

#ETL #Apache_Flink #Apache_Kafka #MongoDB #PostgreSQL #MySQL #Oracle #Microsoft_SQL_Server #OLAP

Рассмотрим нововведения SQL Server Data Tools, связанные со средствами разработки БД для Microsoft SQL Server

Привет, Хабр. Меня зовут Артём, я старший инженер в департаменте аналитических решений ЮMoney. Вас ждёт очень большая статья, в которой мы вместе: ✓ посмотрим на изменения формата файла проекта sqlproj; ✓ разберёмся с новой возможностью публикации dacpac в репозиторий артефактов (например, NuGet) с целью многократного переиспользования в других проектах sqlproj; ✓ напишем анализатор кода tsql на C#, опубликуем его в репозиторий и используем в проекте sqlproj. Приятного чтения! 😊

https://habr.com/ru/companies/yoomoney/articles/883326/

#microsoft_sql_server #nuget #tsql #c# #ssdt

Рассмотрим нововведения SQL Server Data Tools, связанные со средствами разработки БД для Microsoft SQL Server

Привет, Хабр. Меня зовут Артём, я старший инженер в департаменте аналитических решений ЮMoney. Вас ждёт очень большая статья, в которой мы вместе: ✓ посмотрим на изменения формата файла проекта sqlproj; ✓ разберёмся с новой возможностью публикации dacpac в репозиторий артефактов (например, NuGet) с целью многократного переиспользования в других проектах sqlproj; ✓ напишем анализатор кода tsql на C#, опубликуем его в репозиторий и используем в проекте sqlproj. Приятного чтения! 😊

https://habr.com/ru/companies/yoomoney/articles/883326/

#microsoft_sql_server #nuget #tsql #c# #ssdt

Рассмотрим нововведения SQL Server Data Tools, связанные со средствами разработки БД для Microsoft SQL Server

Привет, Хабр. Меня зовут Артём, я старший инженер в департаменте аналитических решений ЮMoney. Вас ждёт очень большая статья, в которой мы вместе: ✓ посмотрим на изменения формата файла проекта sqlproj; ✓ разберёмся с новой возможностью публикации dacpac в репозиторий артефактов (например, NuGet) с целью многократного переиспользования в других проектах sqlproj; ✓ напишем анализатор кода tsql на C#, опубликуем его в репозиторий и используем в проекте sqlproj. Приятного чтения! 😊

https://habr.com/ru/companies/yoomoney/articles/883326/

#microsoft_sql_server #nuget #tsql #c# #ssdt

SQL server: темная сторона AlwaysOn

В SQL server есть замечательная технология - AlwaysOn . Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload. Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов). Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

https://habr.com/ru/articles/836386/

#sql #microsoft_sql_server #alwayson #high_availability

SQL server: темная сторона AlwaysOn

В SQL server есть замечательная технология - AlwaysOn . Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload. Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов). Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

https://habr.com/ru/articles/836386/

#sql #microsoft_sql_server #alwayson #high_availability

SQL server: темная сторона AlwaysOn

В SQL server есть замечательная технология - AlwaysOn . Она используется для DR (disaster recovery, асинхронная репликация данных), HA (high availability, часто с automatic failover, что возможно при синхронной репликации), и для того, что мы обсудим в статье: readonly replica для DWH/OLAP/Reporting workload. Ничто не совершенно (хотя я восхищаюсь простотой установки некоторых решений в MS SQL по сравнению с Postgre и Oracle. Хотя бы бэкапы... А AlwaysOn для маленьких баз заводится буквально в пару кликов). Cегодня мы рассмотрим проблемы при использовании AlwaysOn для DWH/OLAP/Reporting.

https://habr.com/ru/articles/836386/

#sql #microsoft_sql_server #alwayson #high_availability

Инструкция по бэкапу одной базы в Postgres – миф или реальность

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) , до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL , в суровых буднях импортозамещения на Postgres Сохранить в бэкап

https://habr.com/ru/articles/791726/

#бэкап #postgres #pg_dum #microsoft_sql_server #oracle #1c

Инструкция по бэкапу одной базы в Postgres – миф или реальность

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) , до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей то лабораторной работы? Статья адресована прежде всего специалистам 1С избалованным комфортом в MS SQL , в суровых буднях импортозамещения на Postgres Сохранить в бэкап

https://habr.com/ru/articles/791726/

#бэкап #postgres #pg_dum #microsoft_sql_server #oracle #1c