Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Добрый день. Веб-разработке нужна обрезанная копия рабочей базы с возможностью авто-обновления её при изменении схемы продуктива, от пользовательских данных в таблицах нужен минимум (типа топ 100). Сервера разные. Я вижу реализацию похожего через однократное восстановление полной копии рабочей базы с последующей очисткой пользовательских данных до приемлемого размера. Потом уже можно настроить создание доп. копий из неё на убиение и тесты. В этом варианте будут и все объекты и связи нужной БД, нужное количество данных в таблицах. Из минусов - изменение структуры нужно будет накатывать на шаблон. Одновременно плюс - может будут всё на тестовой пробовать сначала, а не часть на тесте, часть на проде. Но рассматриваю и другие варианты. Например, говорят, что когда-то пробовали сделать вариант с обновлением схемы с продуктива, без бекапов - восстановления. Не очень понимаю, как именно думали такое реализовать. Тот же SQL Server Import and Export позволяет перенести данные таблиц и вьюх, но по умолчанию, вроде, только часть данных нельзя проставить. Возможно через вариант с t-sql и топ (100) вместо графики можно обойти это. Но если настроить авто-режим обновления и внести глобальные изменения на проде, то без переделки вроде перестанет отрабатывать. Тестовый запуск все никак не закончится, а то ещё не уверен перенесет ли синонимы, процедуры и т.д. Насколько помню, скорее - нет. Кроме варианта с однократным восстановлением полной копии и последующими с ней действием можно ли как-то получить желаемое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 11:31 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionДобрый день. Веб-разработке нужна обрезанная копия рабочей базы с возможностью авто-обновления её при изменении схемы продуктива, от пользовательских данных в таблицах нужен минимум (типа топ 100). Сервера разные. Я вижу реализацию похожего через однократное восстановление полной копии рабочей базы с последующей очисткой пользовательских данных до приемлемого размера. Потом уже можно настроить создание доп. копий из неё на убиение и тесты. В этом варианте будут и все объекты и связи нужной БД, нужное количество данных в таблицах. Из минусов - изменение структуры нужно будет накатывать на шаблон. Одновременно плюс - может будут всё на тестовой пробовать сначала, а не часть на тесте, часть на проде. Но рассматриваю и другие варианты. Например, говорят, что когда-то пробовали сделать вариант с обновлением схемы с продуктива, без бекапов - восстановления. Не очень понимаю, как именно думали такое реализовать. Тот же SQL Server Import and Export позволяет перенести данные таблиц и вьюх, но по умолчанию, вроде, только часть данных нельзя проставить. Возможно через вариант с t-sql и топ (100) вместо графики можно обойти это. Но если настроить авто-режим обновления и внести глобальные изменения на проде, то без переделки вроде перестанет отрабатывать. Тестовый запуск все никак не закончится, а то ещё не уверен перенесет ли синонимы, процедуры и т.д. Насколько помню, скорее - нет. Кроме варианта с однократным восстановлением полной копии и последующими с ней действием можно ли как-то получить желаемое? В SSIS есть блоки по копированию базы. Потом в пакете урезаете нужные записи. Есть CASCADE, чтобы можно было посносить данные махом. ALTER TABLE T2 ADD CONSTRAINT fk_employee FOREIGN KEY (employeeID) REFERENCES T1 (employeeID) ON DELETE CASCADE; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 17:51 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionКроме варианта с однократным восстановлением полной копии и последующими с ней действием можно ли как-то получить желаемое?Вообще первое, что приходит в голову - репликация. А совсем не копирование, обрезание и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 18:11 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danionнужна обрезанная копия рабочей базыА, обрезанная - имеется в виду "по данным", а не "часть таблиц"? Тогда репликация не тот вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 18:13 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion, вы штаны через голову надеваете. Ведите разработку в проекте VS SSDT, а не на сервере и проблем не будет с развертыванием версий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 22:51 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionВеб-разработке нужна обрезанная копия рабочей базы Причину скажите, от этого и будет зависеть ответ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2019, 23:10 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовDanion, вы штаны через голову надеваете. Ведите разработку в проекте VS SSDT, а не на сервере и проблем не будет с развертыванием версий.Ему же не надо "разворачивать версии", ему нужна копия с обрезанными данными. Независимо от способа работы с проектом, например, в VS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 09:41 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvg, нууу существуют практики загрузки продуктивных справочников в развернутую пустую базу при помощи SSIS пакета. Такой пакет создается максимум за рабочую неделю. Пользовательские же данные формируются непосредственно при тестировании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 13:43 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовalexeyvg, нууу существуют практики загрузки продуктивных справочников в развернутую пустую базу при помощи SSIS пакета. Такой пакет создается максимум за рабочую неделю. Пользовательские же данные формируются непосредственно при тестировании.Это какая то сферическая разработка в ваакуме :-) Для разработки (и тестирования как части процесса) нужна нормальные, полноценные данные. "Сформировать при тестировании" их слишком сложно, так никогда не делают, потому что для этого придётся повторить работу пользователей за достаточно большое время. Соответственно, либо используют продуктовые данные, если они не секретные, либо удаляют секретную чать, либо, если секретность совсем зашкаливает, пишут генераторы данных. Очевидно, у ТС никакой секретности нет, так зачем тратить огромные деньжищи? Видимо, размеры базы немаленькие, раз они не хотят просто использовать копию продуктовой базы (что самое правильное); ну, тогда можно обрезать, причём скрипт обрезания скорее всего будет очень прост, ведь наверняка подавляющее большинство данных лежат в небольшом числе таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 15:50 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvgВидимо, размеры базы немаленькие, раз они не хотят просто использовать копию продуктовой базы (что самое правильное); ну, тогда можно обрезать, причём скрипт обрезания скорее всего будет очень прост, ведь наверняка подавляющее большинство данных лежат в небольшом числе таблиц. Если база действительно большая, то шринк может длиться неделями, что наверняка больше периода обновления тестовой базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 16:32 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
КритикalexeyvgВидимо, размеры базы немаленькие, раз они не хотят просто использовать копию продуктовой базы (что самое правильное); ну, тогда можно обрезать, причём скрипт обрезания скорее всего будет очень прост, ведь наверняка подавляющее большинство данных лежат в небольшом числе таблиц. Если база действительно большая, то шринк может длиться неделями, что наверняка больше периода обновления тестовой базы.Конечно, есть и другие варианты. Можно и перелить, конечно. Но это уж совсем большая база должна быть, что бы шринк делался неприемлемо долго... А писать скрипты для переливки потребует неслабых затрат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 17:49 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Реализация желаемого сценария зависит от сложности физической модели (связи и некоторые пункты из ACID) а так-же целей (использования) которые преследует копия/её создание (какие именно свойства требуются от копии) если например делать топ хххх то вполне вероятно будет нарушение consistency и из-за проблем с несоответствием foreign key на разных концах так что получится вылет с ошибкой. в общем T-SQL скрипт как раньше и говорили нужно будет писать под цели (разработка на репрезентативных выборках / анализ процессов, dev отчетности, data profiling , просто меньший объем для большего быстродействия при разработке и пр.) а так самый простой вариант как уже выше указали - синхронизация схемы (репликация, ну или полностью снести/накатить, сравнение и изменение только отличающихся объектов да добавление/чистка отсутствующих будет более муторно) и наполнение данными (алгоритм зависит от целей как указанно выше) - т.к. обычно truncate или delete.. на измененных объектах с восполнением недостающих или измененных полей - еще та проблема требующего индивидуального подхода в зависимости от случая ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2019, 21:25 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion, У нас используются Prod и Test среды. Тестовая база создавалась из Prod полным беккапом, потом на тест запустили долгоиграющий скрипт, который порционно удалял данные. Ну и когда тестовая скукожилась до разумных размеров, при этом поток свежих данных поступал и на продакшен и на тест одновременно. Тем самым достигалось совпадение на обеих базах отчетов на глубину в 3 месяца. Ну и в конце поставили джоб который ежедневно на тестовой базе устаревшие данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2019, 02:57 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Massa52У нас используются Prod и Test среды. Тестовая база создавалась из Prod полным беккапом, потом на тест запустили долгоиграющий скрипт, который порционно удалял данные. Ну и когда тестовая скукожилась до разумных размеров, при этом поток свежих данных поступал и на продакшен и на тест одновременно. Тем самым достигалось совпадение на обеих базах отчетов на глубину в 3 месяца.У нас используются Prod, Test и Dev среды Dev делался как у вас Test, но далее не поддерживался синхронно (процедура время от времени повторяется, раз в год, например). А Test просто восстанавливается из бакапа Prod, потому что бакап всё равно надо проверять, ну и заодно можно надёжно обкатывать скрипты деплоя, и тестировать новую версию, а так же ковырять сложные ошибки. Считаю такой вариант оптимальным, кроме разве что очень больших баз, для которых тестовое восстановление бакапа никогда не делается, в связи с невозможностью предоставить для этого сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2019, 15:48 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Примерил эту задачку на себя. Возьмите поправку, что я всё стараюсь делать по дурному. Если бы мне надо было отлавливать изменения в структуре таблиц, сделал бы так Связал бы маленькую базу с большой линк сервером. Вспомнил бы простую комманду select * into table2 from table1 table2 создаётся и повторяет структуру table1. Значит перед запуском (ну понятно, что table1 тянется через линк сервер со всеми своими сокращениями) надо сделать глобальный дроп или ренэйм. Прогнать скрипт с индексами и типа всё. А софты, т.е. процедуры, вью, функции я бы автоматике не доверил. Тем более, что массивно их не меняют, так от случая к случаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 09:36 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за ответы. Репликация же подразумевает, что базы синхронизируются, а тут тест по размеру таблиц должен быть урезан. Одна полная копия рабочей базы есть, перезаписывается каждую ночь из бекапов прода. Сейчас хотят ещё несколько меньшего размера за счёт сокращения данных в таблицах, но с сохранением всей структуры. Размер базы 1 ТБ+, есть таблицы 200+млн строк, для проверки столько не нужно. При этом хотят при необходимости быстро создавать новые базы и удалять после. Вот вариант с одной шаблонной базой, с которой будут делаться клоны и показался условно подходящим. "если например делать топ хххх то вполне вероятно будет нарушение consistency и из-за проблем с несоответствием foreign key на разных концах так что получится вылет с ошибкой" а вот это может вылезти... foreign key на таблицах есть. Massa52, "при этом поток свежих данных поступал и на продакшен и на тест одновременно." А это через что достигаете? alexeyvg, Вроде похоже должно выйти на Ваш вариант. С SSIS работал немного, есть смысл в этом направлении копать с данной задачей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 09:48 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionСпасибо всем за ответы. Репликация же подразумевает, что базы синхронизируются, а тут тест по размеру таблиц должен быть урезан. на репле можно настроить фильтр ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 12:08 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
StarikNavyDanionРепликация же подразумевает, что базы синхронизируются, а тут тест по размеру таблиц должен быть урезан. на репле можно настроить фильтрЭто очень непросто сделать, учитывая, что таблиц много, и они связанны. Разве что основной объём приходится на пару таблиц, тогда да. Поставить фильтры на них, а остальное пусть будет необрезанным. Хотя повторю своё ИМХО, лучше вариант, описанный выше , без вот этих сложных плясок. По крайней мере, если нет достаточно точно подсчитанной большой выгоды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 12:43 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionMassa52, "при этом поток свежих данных поступал и на продакшен и на тест одновременно." А это через что достигаете? Данные идут с удаленных компов с таймстемпами(критерий для Top (100...)) на сервер. Все загружается по FTP или в некоторых случаях по SFTP. Далее приложение - Importer распихивает все это в базу. В случае использования Test сервера или еще какого нить сервера - те же данные направляются и на эти сервера. И там происходит то же самое и там естественно свой импотретр, чтобы распихивать данные. Бывает, что на каком нибудь из серверов отваливается соединение. Для нас это не критично и как только соединение восстанавливается, все нормализуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 12:45 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Честно говоря, не хочется городить репликацию на прод. сервере, где для баз данных используется Always On. Вместе их никогда не использовал и не хочется на проде что-то из подводных камней поймать. По размеру выделяется десяток таблиц, но лям+ строк во многих, а столько не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 12:52 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionКроме варианта с однократным восстановлением полной копии и последующими с ней действием можно ли как-то получить желаемое?Если используете Enterprise на боевом и Developer на тестовом, то, возможно, имеет смысл посмотреть на Piecemeal Restores . Если данных так много и нет противопоказаний, то можно включить партиционирование на боевом и забирать и восстанавливать на тестовом только одну-две последних партиции. С readonly придётся дополнительно разбираться. Хотя метод сомнительный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 16:47 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
tunknownDanionКроме варианта с однократным восстановлением полной копии и последующими с ней действием можно ли как-то получить желаемое?Если используете Enterprise на боевом и Developer на тестовом, то, возможно, имеет смысл посмотреть на Piecemeal Restores . Если данных так много и нет противопоказаний, то можно включить партиционирование на боевом и забирать и восстанавливать на тестовом только одну-две последних партиции. С readonly придётся дополнительно разбираться. Хотя метод сомнительный. сразу видно человека, не имевшего дела ни с секционированием, ни с Piecemeal Restore. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 17:31 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Yasha123, Насколько ваше сообщение полезно для ТС? Вопрос риторический... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 23:27 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvgВладислав Колосовalexeyvg, нууу существуют практики загрузки продуктивных справочников в развернутую пустую базу при помощи SSIS пакета. Такой пакет создается максимум за рабочую неделю. Пользовательские же данные формируются непосредственно при тестировании.Это какая то сферическая разработка в ваакуме :-) Для разработки (и тестирования как части процесса) нужна нормальные, полноценные данные. "Сформировать при тестировании" их слишком сложно, так никогда не делают, потому что для этого придётся повторить работу пользователей за достаточно большое время. Соответственно, либо используют продуктовые данные, если они не секретные, либо удаляют секретную чать, либо, если секретность совсем зашкаливает, пишут генераторы данных. Не совсем так, базы как эффективнее тестировать как "коня в вакууме", на синтетических данных по написанным тест-кейсам. Экономится масса времени, т.к. разработчик отходит от "метода тыка" к вполне осознанным проверкам с понятными требованиями. Но к конструировании модели данных должны предъявляться самые строгие требования, не от принятой повсеместно технологии "разрешаем все, а там посмотрим". Скорее "запрещаем всё, а там посмотрим". Для тестирования объемов и вариаций существуют генераторы данных. Недешевые, но и не заоблачно дорогие. Тем самым разработка может вести полностью независимо от продуктовой системы и удалённо. Я не настаиваю, я говорю о том, что это возможно и это работает и, более того, снижает риски. Но требует определённой подготовки и желания этим заниматься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 23:49 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion, Как можно синхронизировать изменения схемы без накатки Alter.... скриптов - без понятия. А для данных можно и впрямь linked Server заюзать. Я бы завёл список таблиц для полного копирования и тех, от которых пару тыщ строк всего надо. И генерил бы Dynamic SQL на основе этих метаданных. Типа merge для одних таблиц и truncate... Insert... Для пользовательских. Заодно можно в метаданных указать top сколько вы хотите. Повторюсь, это я предполагаю, что с изменениями схемы уже как-то разобрались :D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2019, 23:53 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
GlebanskiYasha123, Насколько ваше сообщение полезно для ТС? Вопрос риторический... ну видимо настолько же полезно, насколько и сообщение tunknown. секционирование же "включается" магической кнопкой, раз -- и вдруг во ВСЕХ таблицах терабайтной базы оказался один и тот же ключ секционирования, а функция секционирования так сама собой построилась, что в некоей ФГ оказались, надо же, топ 100 строк каждой таблицы. и то правда, жутко полезный пост для тех кто верит в сказки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 08:23 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Yasha123, Ну по крайней мере ТС задумается, что при ТБ+ базе пора бы уже (некоторые) таблицы партиционировать. А как side-effect получит упрощение процесса "обрезания" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 11:41 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
GlebanskiYasha123, Ну по крайней мере ТС задумается, что при ТБ+ базе пора бы уже (некоторые) таблицы партиционировать. А как side-effect получит упрощение процесса "обрезания" видимо, вы тоже не делали Piecemeal Restore. ибо не знаете, что там нельзя восстановить не пойми какие ФГ, процесс неизбежно начинается с восстановления PRIMARY. насколько я понимаю, сейчас в PRIMARY ТС находится терабайт данных, поэтому, чтобы "как side-effect получить упрощение процесса "обрезания"", придется ТС-у этот терабайт из PRIMARY перемещать в другие ФГ. вы когда-либо терабайт живых данных перемещали "незаметно" для пользователя? товарищ не знает, как по сотне строк выбрать из всех таблиц, а предлагаемый вариант подразумевает перемещение вообще всех данных. еще хотелось бы посмотреть на "общий" для всех таблиц ключ секционирования + на рефакторинг всего имеющегося кода, ибо в "секционированном" варианте базы в фильтр запросов надо еще и ключ секционирования вписывать, иначе получите только очередные тормоза из-за просмотра уж я не знаю скольких секций (кажется, в секцию должны 100 строк войти?) в стольких же ФГ (ибо если все оставить в PRIMARY, то и никакого вам Piecemeal Restore) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 12:23 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Yasha123 насколько я понимаю, сейчас в PRIMARY ТС находится терабайт данных, поэтому, чтобы "как side-effect получить упрощение процесса "обрезания"", придется ТС-у этот терабайт из PRIMARY перемещать в другие ФГ. Ну вот этого мы как раз и не знаем. Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз (хотя вот щас вспомнил, что как раз у коллеги последний проект такой был ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 12:43 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion, озвучьте пожалуйста размер вашей PRIMARY ФГ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 12:55 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
"Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз" Для большинство можно. Я когда-то с 4 ТБ базой работал, где ответственные не хотели ничего о разбитии слышать. "Какое секционирование? Мы таких слов не знаем!" База создана давно, разрешение на изменение сейчас получить сложно. Разработчик T-sql отсутствует как класс. Соответственно 1 файловая группа PRIMARY. Секционирования при одном ФГ не делается. На нескольких таблицах иногда делается перенос данных в аля-архивные таблицы. Планируется в будущем переезд на новый сервер, может удастся протолкнуть изменения в конфигурации при этом. Продолжаю уточнять желания разработчиков. Уже выходит не по "100 строк из таблицы", а часть нужно полностью, от больших месяц, а несколько в пустом виде. (При этом на большой таблице индекса на дату нет, в стандартных запросах больше через номер идёт). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 14:15 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion"Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз" Для большинство можно. Я когда-то с 4 ТБ базой работал, где ответственные не хотели ничего о разбитии слышать. "Какое секционирование? Мы таких слов не знаем!" База создана давно, разрешение на изменение сейчас получить сложно. Разработчик T-sql отсутствует как класс.Вообще 4 Тб сейчас не какой то экстремально большой объём. Я бы сделал там секционирование, если оно уж очень сильно напрашивается из бизнес-логики данных. Ну и вобще, первый вопрос, который нужно задать, "сколько бизнес получит денег от внедрения секционирования?". Пока я вижу только затраты на T-sql разработчика :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 14:55 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Это и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато. Контора с белой зарплатой, ставки разрабов высоки и говорят, что проще купить новую железку, чем оплачивать разраба + налоги, пенсионку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 15:30 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danionalexeyvg, Это и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато. Контора с белой зарплатой, ставки разрабов высоки и говорят, что проще купить новую железку, чем оплачивать разраба + налоги, пенсионку.Ага. Сначала купить новую железку, а потом еще оплачивать разраба + налоги, пенсионку, когда толку от новой железки будет 0 (а то еще и хуже станет). Ну да ладно, лирика это, бизнесу виднее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 15:36 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
DanionЭто и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато.Ну, веб-разработчикам тоже надо платить :-) Я, собственно не против отдельного квалифицированного специалиста по сиквелу, я считаю, что он нужен обязательно, я больше говорю про секционирование - оно нужно не так часто, как думают те, кто его никогда не применал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 17:13 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvgя больше говорю про секционирование - оно нужно не так часто, как думают те, кто его никогда не применал. вот я про то же. особенно это касается тех, кто считает, что секционирование "включают", а что терабайт данных придется переливать, что глобальная уникальность полетит к чертям, что все планы полетят туда же, это за кадром. и особенно интересно слышать о секционировании по причине возможности "потом делать Piecemeal Restore". так что присоединяюсь к мнению, что присоветовал это один из тех, "кто его никогда не применял" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 17:35 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
Danion, Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 17:36 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
GlebanskiDanion, Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ? и в чем смысл такого "раскидывания"? ну пускай у меня 10 жирных таблиц по 100Гб. я их разнесу на 10 различных ФГ, секционирования нет. теперь мне надо по 100 строк из этих таблиц получить классным способом "Piecemeal Restore". мне нужны данные из всех десяти таблиц, так что мне, восстанавливать все 10 ФГ? т.е. я вместо одного бэкапа в терабайт восстановлю 10 по 100Гб, и в чем-то выиграю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 17:52 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
GlebanskiDanion, Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ? sp_rename не позволяет раскидать по файлгруппам. И копирование в другую файлгруппу остановит сервис на приличное ывремя, если таблицы большие. Это же тупое копирование данных. Не говоря уже о том, что разнесение по файлгруппам имеет для ТС ценности ровно 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 18:33 |
|
||
|
Обновляемая обрезанная копия рабочей базы
|
|||
|---|---|---|---|
|
#18+
alexeyvgGlebanskiDanion, Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ? sp_rename не позволяет раскидать по файлгруппам. как я понимаю, товарищ предложил скопировать данные в другую ФГ, а потом полученную табличку в другой ФГ переименовать, дропнув прежнюю. переименовать можно, хоть бы таблицы и в разных ФГ были. (ФК, правда, продолжат смотреть на прежнюю таблицу, даже переименованную) но переотправить ему вопрос: "Насколько ваше сообщение полезно для ТС?" вполне законно, ибо еще раз: ну разнесли таблицы по разным ФГ, и что? вы же их целиком перенесли, как это поможет "отресторить" на другой сервер 100 строк каждой таблицы? короче, забейте вы уже на этот Piecemeal Restore. ну никаким он тут боком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2019, 18:55 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1688025]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 380ms |

| 0 / 0 |
