Системы управления базами данных
Добавление сообщений к этой теме для
незарегистрированных пользователей невозможно
Вы не можете создавать новые темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
![[<]](/img/previous.gif "Предыдущая тема"){kind=small}
![[>]](/img/next.gif "Следующая тема"){kind=small}
Быстрый переход![[]](/img/iprint.gif "Версия для печати"){kind=small}
U-Cesar
писатель
Сообщений: 2 787
Дискуссия
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Дискуссия
--------------------
U-Cesar
писатель
Сообщений: 2 787
--------------------
U-Cesar
писатель
Сообщений: 2 787
По специализации "системщик", волею судьбы пришлось "занырнуть" в базы.
Когда-то изучал, но не глубоко. На курсах по MsSQL, 7-ую, ЕМНИП, версию.
Ну так вот. Имею задание реализовать бд. Причём, те, кто ставил задачу, в силу разных причин, слабо соображают в предметной области.
Мой мотив, кроме профита от опыта, следующий - хочу оставить после себя некую работающую систему. Чтобы человек пришёл, запустил, разобрался и стал работать.
Работа в определённой степени неблагодарная, большой объём, но ещё больше времени, я так подозреваю, уйдёт на утрясание ИМХОв начальства etc
Но лавры и пьедестал меня интересуют мало (хватает этого добра в жизни)))
Предполагаю связку линукс + пострес/мускуль. Ну, и интерфейс под винду.
Особо волнует: жизненный цикл и защита "от дурака", расширяемость.
Возможно, у Вас есть некий опыт...
Счас активно "вкуриваю" теорию.
В соседнем топике прочёл Ваши рекомендации по поводу англоязычной литературы... В чём причина? Неадекватный перевод на русский?
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
По специализации "системщик", волею судьбы пришлось "занырнуть" в базы.
Когда-то изучал, но не глубоко. На курсах по MsSQL, 7-ую, ЕМНИП, версию.
Ну так вот. Имею задание реализовать бд. Причём, те, кто ставил задачу, в силу разных причин, слабо соображают в предметной области.
Мой мотив, кроме профита от опыта, следующий - хочу оставить после себя некую работающую систему. Чтобы человек пришёл, запустил, разобрался и стал работать.
Работа в определённой степени неблагодарная, большой объём, но ещё больше времени, я так подозреваю, уйдёт на утрясание ИМХОв начальства etc
Но лавры и пьедестал меня интересуют мало (хватает этого добра в жизни)))
Предполагаю связку линукс + пострес/мускуль. Ну, и интерфейс под винду.
Особо волнует: жизненный цикл и защита "от дурака", расширяемость.
Возможно, у Вас есть некий опыт...
Счас активно "вкуриваю" теорию.
В соседнем топике прочёл Ваши рекомендации по поводу англоязычной литературы... В чём причина? Неадекватный перевод на русский?
Про расширяемость: предел есть у любой системы, когда добавление небольшого объема данных начнет приводить к серьезному ухудшению производительности. Вы, кстати, какую по предполагаемом объему систему пишете? Под какое железо (хотя этот вопрос актуален скорее для очень больших систем, но все таки)? Под какие задачи? Онлайн или data Warehouse?
Защита от дурака тоже реализуется по-разному в разных СУБД. Насколько я понимаю, Вы MS SQL собрались использовать?
Приведу пример "защиты от дурака" в DB2. В DB2 для выполнения статической хранимой процедуры пользователю требуется только права на выполнение и не требуются явные права на объекты, использованные в хранимой процедуре. Пользователю, под которым ваше приложение будет ходить на базу, выдают права на выполнение хранимых процедур и не выдают явно права на таблицы и т.д. В результате пользователь может совершать только действия, разрешенные в хранимой процедуре. В MS SQL ситуация немного другая - там зачастую необходимы явные права на объекты. Про Оракл не подскажу - с ним не работала.
Иногда часть данных можно "закрыть", создав view, но это скорее "позволить видеть определенные столбцы в таблице". Строк это касаться не будет (если вы не решите создавать на каждого пользователя своей базы отдельное view, что делать я Вам не советую, особенно если пользователей больше 10
Но это так, сильно общая теория.
Если это не является конфиденциальной информацией, давайте пообщаемся более предметно: что именно делается, какая задача решается, предполагаемый объем данных. Чем смогу - помогу
--------------------
U-Cesar
писатель
Сообщений: 2 787
--------------------
R0bur
писатель
Сообщений: 1 536
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Прошу прощения, продолжайте, пожалуйста
--------------------
R0bur
писатель
Сообщений: 1 536
Для синхронизации диалога сообщаю, что речь с высокой степенью вероятности шла о PostgreSQL и MySQL
--------------------
U-Cesar
писатель
Сообщений: 2 787
Речь идёт о:
1 - ОС linux
2 - СУБД PostgreSQL или MySQL (не решил ещё)
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Речь идёт о:
1 - ОС linux
2 - СУБД PostgreSQL или MySQL (не решил ещё)
Мой первый wild guess был, что Вы имеете в виду My SQL. Но из опыта (даже на соседней ветке такое имело место) My SQL часто путают с MS SQL. Вот отсюда и выросли "непонятки".
Непосредственно с PostgreSQL я не работала (это я так, предупреждаю), но будет шанс освоить еще одну СУБД к уже имеющимся.
--------------------
R0bur
писатель
Сообщений: 1 536
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
1. DB2 V8 + Windows. Кластер. Репликация. Распределенная система (1 центральная база, несколько региональных). Data warehouse - AS400. Приложение самописное.
2. DB2 V9 + AIX. HADR. Data warehouse - mainframe + DB2 for z/OS. Приложение покупное from the box (будь оно неладно) .
--------------------
U-Cesar
писатель
Сообщений: 2 787
В общем, на неделе набросаю своё видение решения задачи и буду думать.
Проблема усугубляется двумя вещами:
1 - неопределённостью с техническим заданием со стороны руководства
2 - и, как следствие, отсутствием полномочий на утрясание рабочих моментов.
Что до остального, то я сам кагбэ не "копенгаген" в СУБДах, разбираюсь "на лету".
--------------------
U-Cesar
писатель
Сообщений: 2 787
--------------------
R0bur
писатель
Сообщений: 1 536
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Регионы генерируют информацию, которая этими же базами и обрабатывается. Доступа у офиса в Ростове к счету, открытому в Красноярске нет и быть не должно. Только возможность снятия денег в банкомате. В центр стекается информация со всех регионалок. Используется для учета, статистики + банкоматы. Такая архитектура хороша, потому что в одну нагруженную в режиме онлайн базу в одну и ту же таблицу не складывают информацию, которая никогда не будет использована вместе. Зачем искусственно увеличивать нагрузку на онлайн?
--------------------
R0bur
писатель
Сообщений: 1 536
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Но если Вы намекаете на разницу во времени в пиковых нагрузках, то это, конечно, имеет место. Другое дело, что большая часть офисов расположена +1-2 часа от центрального. На них и приходится наибольшая нагрузка (по объему транзакций). Так что сильного распределения пиковой нагрузки в случае использования единой базы не получается.
Плюс для реализации требования "офис из одного региона не должен иметь доступ к данным счета из другого региона" пришлось бы реализовывать механизм привязки офиса к региону и клиента к региону. А это сразу ненужная нагрузка на производительность.
Проще (и в логическом и в техническом смысле) было сделать распределенную систему.
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Дано: система из 3 компонент. компонент 1: онлайн система. Компонент 2: Батчи, синхронихирующие онлайн базу с головной базой. Компонент 3: технические батчи (бекап, сбор статистики и т.д.)
База данных - DB2.
Сделано: онлайн компонент переписали, внедрили использование кэширования данных на уровне приложения. Кэш самописный и сильно топорный. Тонкий момент - батчи используют те же .jar файлы, что и онлайн.
После установки нового кода наблюдается:
1. с батч-сервера идет транзакции, которые одномоментно держат по 3500 х-локов (эксклюзивный лок на объект. Остальные курят бамбук и ждут доступа к этому объекту. Среднее время ожидания - 10 минут). Из-за этого периодически подвисает онлайн.
2. технические батчи, которые используют стандартные утилиты DB2 (RUNSTATS) стали блокировать онлайн - несовместимость локов, онлайн ждет лока от утилиты сбора статистики по табличке, а таблички у нас по 300 гигов.
3. количество .log файлов сильно возросло (что свидетельствует об увеличении количества операций изменения/вставки/удаления данных). В Продакшене сейчас за день генерится 100 .log файлов при нагрузке в 17.000 пользователей в час, в тестовой среде при 10 тестерах - 50 файлов. Ограничение количества активных .log файлов в продакшене - 200, + еще 200 архивных. Раз в сутки архивные файлы уезжают на ленты.
Собственно вопрос (вернее вопросы):
1. Считаете ли Вы, что данное изменение поведения системы связано с внедрением нового кода?
2. Считаете ли вы необходимым проведения нагрузочного тестирования всех 3 компонент данной системы (нагрузочное тестирование онлайна проводилось, тест пройден)?
3. Считаете ли Вы, что это все благополучно накроется в Продакшн медным тазиком (т.е. будет неработоспособным)?
П.С. свое мнение у меня имеется, просто интересно задать задачку окружающим и послушать их мнение.
--------------------
Igoroshka
графоман
Сообщений: 4 112
1. DB2 V8 + Windows. Кластер. Репликация. Распределенная система (1 центральная база, несколько региональных). Data warehouse - AS400. Приложение самописное.
2. DB2 V9 + AIX. HADR. Data warehouse - mainframe + DB2 for z/OS. Приложение покупное from the box (будь оно неладно) .
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?
--------------------
Igoroshka
графоман
Сообщений: 4 112
Дано: система из 3 компонент. компонент 1: онлайн система. Компонент 2: Батчи, синхронихирующие онлайн базу с головной базой. Компонент 3: технические батчи (бекап, сбор статистики и т.д.)
База данных - DB2.
Сделано: онлайн компонент переписали, внедрили использование кэширования данных на уровне приложения. Кэш самописный и сильно топорный. Тонкий момент - батчи используют те же .jar файлы, что и онлайн.
После установки нового кода наблюдается:
1. с батч-сервера идет транзакции, которые одномоментно держат по 3500 х-локов (эксклюзивный лок на объект. Остальные курят бамбук и ждут доступа к этому объекту. Среднее время ожидания - 10 минут). Из-за этого периодически подвисает онлайн.
2. технические батчи, которые используют стандартные утилиты DB2 (RUNSTATS) стали блокировать онлайн - несовместимость локов, онлайн ждет лока от утилиты сбора статистики по табличке, а таблички у нас по 300 гигов.
3. количество .log файлов сильно возросло (что свидетельствует об увеличении количества операций изменения/вставки/удаления данных). В Продакшене сейчас за день генерится 100 .log файлов при нагрузке в 17.000 пользователей в час, в тестовой среде при 10 тестерах - 50 файлов. Ограничение количества активных .log файлов в продакшене - 200, + еще 200 архивных. Раз в сутки архивные файлы уезжают на ленты.
Собственно вопрос (вернее вопросы):
1. Считаете ли Вы, что данное изменение поведения системы связано с внедрением нового кода?
2. Считаете ли вы необходимым проведения нагрузочного тестирования всех 3 компонент данной системы (нагрузочное тестирование онлайна проводилось, тест пройден)?
3. Считаете ли Вы, что это все благополучно накроется в Продакшн медным тазиком (т.е. будет неработоспособным)?
П.С. свое мнение у меня имеется, просто интересно задать задачку окружающим и послушать их мнение.
Из общих соображений.
1. Эксклюзивные блокировки на уровне таблицы/экстента/строки?
2. Есть ли возможность развести во времени онлайн и, по крайней мере, технические пакетные задания?
3. Есть ли в DB2 такое понятие как standby server? Если есть, почему бы не использовать его для выполнения резервного копирования?
4. Есть ли необходимость в постоянном обновлении статистики? Насколько меняются распределения, если сделать задержку со сбором? Есть ли такое понятие как динамическая статистика?
5. Есть ли возможность снять, например, дневную загрузку производственного сервера с последующим применением нагрузки на тестовой системе для моделирования реальной нагрузки?
6. Рассматривали ли вы вопрос создания параллельного сервера (например, с использованием GoldenGate) для пакетных заданий, чтобы разгрузить основной онлайн сервер?
--------------------
Igoroshka
графоман
Сообщений: 4 112
2. Считаете ли вы необходимым проведения нагрузочного тестирования всех 3 компонент данной системы (нагрузочное тестирование онлайна проводилось, тест пройден)?
3. Считаете ли Вы, что это все благополучно накроется в Продакшн медным тазиком (т.е. будет неработоспособным)?
П.С. свое мнение у меня имеется, просто интересно задать задачку окружающим и послушать их мнение.
2. Должно выполняться нагрузочное тестирование всей системы по крайней мере в рамках типовой нагрузки.
3. Если будет генерироваться большое количество изменений, количество журнальных файлов может резко увеличиться. Если система не позволяет на лету увеличивать количество/размер журнальных файлов (на сколько я понимаю, речь идет о циклическом буфере журналов), система "сложится".
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Из общих соображений.
1. Эксклюзивные блокировки на уровне таблицы/экстента/строки?
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Этого я как раз и опасаюсь. Архивные логи чистятся ночью, вопрос только дотянем ли мы до ночи с таким резким ростом логов. Система под нагрузкой больше 2-3- часов не тестировалась.
Собственно суть проблемы: нашла коса на камень. Я говорю, что ставить это в продакшн без нагрузочного тестирования хотя бы 24 часа "в полной выкладке" (т.е. онлайн+батчи+runstats) нельзя. Архитектор вендора, который делал кэш для онлайна, говорит, что можно, якобы они батчи не зацепили своими изменениями. НО! Батчи используют те же .jar файлы, что и онлайн. К тому же поведение батчей изменилось.
А мне говорят: времени до продакшна осталось 2 недели, тестировать не будем, потом протестируем после продакшна.
Каковы Ваши прогнозы, господа? Крякнется это все в продакшене или нет?
--------------------
Igoroshka
графоман
Сообщений: 4 112
Посмотрел определение HADR. Классический standby. Неужели нельзя на него вынести хотя бы резервное копирование данных?
К сожалению, не знаю многих особенностей операционки. Но, насколько я помню, технически возможно увеличить размер файловой системы на лету. Другое дело, есть ли такое количество доступного дискового пространства нужного типа на используемой дисковой стойке?
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
.
Ага. С минимальными изменениями данных и в пределах 2-часового интервала, когда статистика еще актуальна. А если предложить им хотя бы запустить тест без сбора статистики через сутки после существенных изменений? И сравнить и время выполнения, и планы запросов?
К сожалению, не знаю многих особенностей операционки. Но, насколько я помню, технически возможно увеличить размер файловой системы на лету. Другое дело, есть ли такое количество доступного дискового пространства нужного типа на используемой дисковой стойке?
Правильно ли я понимаю, что при заполнении области архивных журналов, система продолжает работать, создавая активные журналы, но без архивных копий? Если так, то падение стойки будет означать не только падения сервера, но и возможную потерю базы со всеми вытекающими отсюда последствиями. Не знаю особенностей работы резервного сервера. Но, по логике, он должен актуализировать данные основного сервера. До тех пор, пока на него передаются архивные журналы. Т.е., получается, резервный сервер окажется с задержкой во времени.
При резервном копировании?
вы задаете количество активных лог-файлов. Например 20. И количество вторичных лог файлов (например, 20). Это прописывается в настройках самой базы. Далее вы задаете механизм, как базе поступать со старыми лог файлами. это может быть "Оставлять в той же директории, что и активные файлы, мы сами все куда надо скопируем и почистим". Проблема этого метода - надо постоянно чистить (копировать логи например на ленту) и удалять скопированные лог-файлы. Второй механизм: "в директории оставлять только активные и вторичные файлы. Более старые при наличии возможности перемещать в архивную директорию. Чистить придется архивную директорию". Проблема та же, но чистить придется только архивную директорию, унося файлы на ленты. Если архивная директория забита, то старые лог файлы не перемещаются в архивную директорию, а остаются в активной. активная лог-директория это отдельная файловая система. постепенно она тоже забивается. Места для следующего лог-файлы не остается, база падает.
ТО есть архивная директория - это не копия активной. Каждый файл логов существует в единственном экземпляре: или в активной директории, или а архивной, или на ленте.
перемещение файлов из архивной директории на ленту происходит ночью.
Вот оттуда и мой вопрос: хватит ли нам места в активных и архивных директориях, доживем ли до ночи?
Каков бы ни был исход, подход принципиально не правильный.
--------------------
Igoroshka
графоман
Сообщений: 4 112
Как часто журналы переключаются/ротируются? Возможно ли по статистике оценить объем журнала на транзакцию/пользователя в промышленной и тестовой системах? Сколько транзакций в секунду выполняется? Какая сдерняя длительность транзакции в обоих системах? Если транзакция длительная, она распределяется по разным логам?
--------------------
nati_vostrikova
графоман
Сообщений: 6 353
Как часто журналы переключаются/ротируются? Возможно ли по статистике оценить объем журнала на транзакцию/пользователя в промышленной и тестовой системах? Сколько транзакций в секунду выполняется? Какая сдерняя длительность транзакции в обоих системах? Если транзакция длительная, она распределяется по разным логам?
Размер файлов одинаковый в тесте и продакшене - 4 MB.
П.С. Вот и получилась дискуссия
--------------------
Igoroshka
графоман
Сообщений: 4 112
П.С. Вот и получилась дискуссия
В этой ситуации могу посоветовать только одно: создать план перехода, максимально учитывающий возможные проблемы. В плане прописать кто, что, когда и сколько времени делает. Определить возможные точки отката/невозврата и кто и на основе каких критериев принимает решение о продолжении переходи или возвращении на старую систему.
Отдельно -- ресурсный план, где прописать возможные требования по увеличению дискового пространства, процессорных квот (если используются LPARы).
Удачи!
---------------------
Если можно, пару слов о:
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?
--------------------