powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Обновляемая обрезанная копия рабочей базы
15 сообщений из 40, страница 2 из 2
Обновляемая обрезанная копия рабочей базы
    #39794931
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebanskiYasha123,

Насколько ваше сообщение полезно для ТС?
Вопрос риторический...
ну видимо настолько же полезно,
насколько и сообщение tunknown.

секционирование же "включается" магической кнопкой,
раз -- и вдруг во ВСЕХ таблицах терабайтной базы
оказался один и тот же ключ секционирования,
а функция секционирования так сама собой построилась, что в некоей ФГ
оказались, надо же, топ 100 строк каждой таблицы.

и то правда, жутко полезный пост для тех кто верит в сказки
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795040
Glebanski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yasha123,

Ну по крайней мере ТС задумается, что при ТБ+ базе пора бы уже (некоторые) таблицы партиционировать. А как side-effect получит упрощение процесса "обрезания"
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795084
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebanskiYasha123,

Ну по крайней мере ТС задумается, что при ТБ+ базе пора бы уже (некоторые) таблицы партиционировать. А как side-effect получит упрощение процесса "обрезания"
видимо, вы тоже не делали Piecemeal Restore.
ибо не знаете, что там нельзя восстановить не пойми какие ФГ,
процесс неизбежно начинается с восстановления PRIMARY.

насколько я понимаю, сейчас в PRIMARY ТС находится терабайт данных,
поэтому, чтобы "как side-effect получить упрощение процесса "обрезания"",
придется ТС-у этот терабайт из PRIMARY перемещать в другие ФГ.

вы когда-либо терабайт живых данных перемещали "незаметно" для пользователя?

товарищ не знает, как по сотне строк выбрать из всех таблиц,
а предлагаемый вариант подразумевает перемещение вообще всех данных.

еще хотелось бы посмотреть на "общий" для всех таблиц ключ секционирования
+ на рефакторинг всего имеющегося кода,
ибо в "секционированном" варианте базы в фильтр запросов надо еще и ключ секционирования вписывать,
иначе получите только очередные тормоза из-за просмотра уж я не знаю скольких секций
(кажется, в секцию должны 100 строк войти?)
в стольких же ФГ (ибо если все оставить в PRIMARY, то и никакого вам Piecemeal Restore)
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795099
Glebanski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yasha123
насколько я понимаю, сейчас в PRIMARY ТС находится терабайт данных,
поэтому, чтобы "как side-effect получить упрощение процесса "обрезания"",
придется ТС-у этот терабайт из PRIMARY перемещать в другие ФГ.


Ну вот этого мы как раз и не знаем. Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз (хотя вот щас вспомнил, что как раз у коллеги последний проект такой был )
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795107
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Danion,
озвучьте пожалуйста размер вашей PRIMARY ФГ
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795177
Danion
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз" Для большинство можно. Я когда-то с 4 ТБ базой работал, где ответственные не хотели ничего о разбитии слышать. "Какое секционирование? Мы таких слов не знаем!"

База создана давно, разрешение на изменение сейчас получить сложно. Разработчик T-sql отсутствует как класс.
Соответственно 1 файловая группа PRIMARY. Секционирования при одном ФГ не делается.
На нескольких таблицах иногда делается перенос данных в аля-архивные таблицы.

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

Продолжаю уточнять желания разработчиков. Уже выходит не по "100 строк из таблицы", а часть нужно полностью, от больших месяц, а несколько в пустом виде. (При этом на большой таблице индекса на дату нет, в стандартных запросах больше через номер идёт).
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795204
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Danion"Конечно можно подозревать самое худшее, но зачем сразу вешать клеймо "без понятия шо такое FG" на всех владельцев терабайтных баз" Для большинство можно. Я когда-то с 4 ТБ базой работал, где ответственные не хотели ничего о разбитии слышать. "Какое секционирование? Мы таких слов не знаем!"

База создана давно, разрешение на изменение сейчас получить сложно. Разработчик T-sql отсутствует как класс.Вообще 4 Тб сейчас не какой то экстремально большой объём. Я бы сделал там секционирование, если оно уж очень сильно напрашивается из бизнес-логики данных.

Ну и вобще, первый вопрос, который нужно задать, "сколько бизнес получит денег от внедрения секционирования?". Пока я вижу только затраты на T-sql разработчика :-)
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795241
Danion
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
alexeyvg,

Это и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато.

Контора с белой зарплатой, ставки разрабов высоки и говорят, что проще купить новую железку, чем оплачивать разраба + налоги, пенсионку.
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795246
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Danionalexeyvg,

Это и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато.

Контора с белой зарплатой, ставки разрабов высоки и говорят, что проще купить новую железку, чем оплачивать разраба + налоги, пенсионку.Ага. Сначала купить новую железку, а потом еще оплачивать разраба + налоги, пенсионку, когда толку от новой железки будет 0 (а то еще и хуже станет).

Ну да ладно, лирика это, бизнесу виднее.
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795340
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DanionЭто и ответ, почему разработка только со стороны веб. Хотя на мой взгляд - весьма желательна оптимизация базы с переработкой её структуры. Тут скорее будет не сколько бизнес заработает, а сколько не потеряет на тормозах и блокировках. +Плюс затраты на ресурсы. Но связки 1 DBA + разрабы веба для переработки 24*7 проекта маловато.Ну, веб-разработчикам тоже надо платить :-)

Я, собственно не против отдельного квалифицированного специалиста по сиквелу, я считаю, что он нужен обязательно, я больше говорю про секционирование - оно нужно не так часто, как думают те, кто его никогда не применал.
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795356
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgя больше говорю про секционирование - оно нужно не так часто, как думают те, кто его никогда не применал.
вот я про то же.
особенно это касается тех,
кто считает, что секционирование "включают",
а что терабайт данных придется переливать,
что глобальная уникальность полетит к чертям,
что все планы полетят туда же,
это за кадром.
и особенно интересно слышать о секционировании
по причине возможности "потом делать Piecemeal Restore".

так что присоединяюсь к мнению,
что присоветовал это один из тех,
"кто его никогда не применял"
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795359
Glebanski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Danion,

Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ?
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795372
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebanskiDanion,

Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ?
и в чем смысл такого "раскидывания"?
ну пускай у меня 10 жирных таблиц по 100Гб.
я их разнесу на 10 различных ФГ,
секционирования нет.
теперь мне надо по 100 строк из этих таблиц получить классным способом "Piecemeal Restore".
мне нужны данные из всех десяти таблиц,
так что мне, восстанавливать все 10 ФГ?
т.е. я вместо одного бэкапа в терабайт восстановлю 10 по 100Гб, и в чем-то выиграю?
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795384
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebanskiDanion,

Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ?
sp_rename не позволяет раскидать по файлгруппам.
И копирование в другую файлгруппу остановит сервис на приличное ывремя, если таблицы большие. Это же тупое копирование данных.
Не говоря уже о том, что разнесение по файлгруппам имеет для ТС ценности ровно 0.
...
Рейтинг: 0 / 0
Обновляемая обрезанная копия рабочей базы
    #39795389
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgGlebanskiDanion,

Ну если секционировать не возьметесь, то уж самые жирные таблицы по отдельным FG раскидать - задача вполне реализуемая. У вас же не не 99.99999% availability, найдете пару минут на финальный sp_rename ?
sp_rename не позволяет раскидать по файлгруппам.

как я понимаю, товарищ предложил скопировать данные в другую ФГ,
а потом полученную табличку в другой ФГ переименовать, дропнув прежнюю.
переименовать можно, хоть бы таблицы и в разных ФГ были.
(ФК, правда, продолжат смотреть на прежнюю таблицу, даже переименованную)

но переотправить ему вопрос: "Насколько ваше сообщение полезно для ТС?" вполне законно,
ибо еще раз: ну разнесли таблицы по разным ФГ, и что?
вы же их целиком перенесли, как это поможет "отресторить" на другой сервер 100 строк каждой таблицы?

короче, забейте вы уже на этот Piecemeal Restore.
ну никаким он тут боком.
...
Рейтинг: 0 / 0
15 сообщений из 40, страница 2 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Обновляемая обрезанная копия рабочей базы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]