80

Тут говорят!
Авторизация
Список форумов
Войти через акаунт
 

Системы управления базами данных
Подписаться/отписаться на тему (функция доступна только для зарегистрированных пользователей) Любимая тема (вкл/выкл) []

Страницы: 1  2  3  4  5   из  8
Добавление сообщений к этой теме для незарегистрированных пользователей невозможно
Тему смотрит 1 незарегистрированный пользователь
Модераторы
Рейтинг темы: ***** (55709 просмотров)
Вы не можете создавать новые темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

Масштабируемость, разработка приложений, опыт эксплуатации, жизненный цикл, защита данных.
Дискуссия

--------------------
momento mori
Момент - и в море (ц)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

U-Cesar (01.02.12 08:59) писал(a):
Масштабируемость, разработка приложений, опыт эксплуатации, жизненный цикл, защита данных.
Дискуссия
Senior DB2 DBA/ Data Architect. Сфера деятельности - банковская. Как собеседник подойду?

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (09.02.12 04:36) писал(a):
Senior DB2 DBA/ Data Architect. Сфера деятельности - банковская. Как собеседник подойду?
Вполне. ))

--------------------
momento mori
Момент - и в море (ц)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (09.02.12 04:36) писал(a):
Senior DB2 DBA/ Data Architect. Сфера деятельности - банковская. Как собеседник подойду?
Я, в некотором роде, в базах неофит. Если не считать пары-тройки проектов (систем учёта на базе linux + MySQL).
По специализации "системщик", волею судьбы пришлось "занырнуть" в базы.
Когда-то изучал, но не глубоко. На курсах по MsSQL, 7-ую, ЕМНИП, версию.
Ну так вот. Имею задание реализовать бд. Причём, те, кто ставил задачу, в силу разных причин, слабо соображают в предметной области.
Мой мотив, кроме профита от опыта, следующий - хочу оставить после себя некую работающую систему. Чтобы человек пришёл, запустил, разобрался и стал работать.
Работа в определённой степени неблагодарная, большой объём, но ещё больше времени, я так подозреваю, уйдёт на утрясание ИМХОв начальства etc
Но лавры и пьедестал меня интересуют мало (хватает этого добра в жизни)))
Предполагаю связку линукс + пострес/мускуль. Ну, и интерфейс под винду.
Особо волнует: жизненный цикл и защита "от дурака", расширяемость.
Возможно, у Вас есть некий опыт...
Счас активно "вкуриваю" теорию.
В соседнем топике прочёл Ваши рекомендации по поводу англоязычной литературы... В чём причина? Неадекватный перевод на русский?

--------------------
momento mori
Момент - и в море (ц)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

U-Cesar (10.02.12 13:03) писал(a):
Я, в некотором роде, в базах неофит. Если не считать пары-тройки проектов (систем учёта на базе linux + MySQL).
По специализации "системщик", волею судьбы пришлось "занырнуть" в базы.
Когда-то изучал, но не глубоко. На курсах по MsSQL, 7-ую, ЕМНИП, версию.
Ну так вот. Имею задание реализовать бд. Причём, те, кто ставил задачу, в силу разных причин, слабо соображают в предметной области.
Мой мотив, кроме профита от опыта, следующий - хочу оставить после себя некую работающую систему. Чтобы человек пришёл, запустил, разобрался и стал работать.
Работа в определённой степени неблагодарная, большой объём, но ещё больше времени, я так подозреваю, уйдёт на утрясание ИМХОв начальства etc
Но лавры и пьедестал меня интересуют мало (хватает этого добра в жизни)))
Предполагаю связку линукс + пострес/мускуль. Ну, и интерфейс под винду.
Особо волнует: жизненный цикл и защита "от дурака", расширяемость.
Возможно, у Вас есть некий опыт...
Счас активно "вкуриваю" теорию.
В соседнем топике прочёл Ваши рекомендации по поводу англоязычной литературы... В чём причина? Неадекватный перевод на русский?
Причина проще: в РБ к архитектуре данных относятся несерьезно, хотя именно база данных определяет производительность системы. Поэтому хорошие книги по оптимизации и архитектуре данных на русский просто не переводят. По крайней мере под видом "методички" в прошлом топике пришлось подсунуть собственную книжку в самом черновом варианте - аналогов на русском я просто предложить не смогла. Проблема в том, что в русскоязычных книжках Вам рассказывают про объекты базы данных и т.д., но не рассказывают, что ими реализуется и как.

Про расширяемость: предел есть у любой системы, когда добавление небольшого объема данных начнет приводить к серьезному ухудшению производительности. Вы, кстати, какую по предполагаемом объему систему пишете? Под какое железо (хотя этот вопрос актуален скорее для очень больших систем, но все таки)? Под какие задачи? Онлайн или data Warehouse?

Защита от дурака тоже реализуется по-разному в разных СУБД. Насколько я понимаю, Вы MS SQL собрались использовать?
Приведу пример "защиты от дурака" в DB2. В DB2 для выполнения статической хранимой процедуры пользователю требуется только права на выполнение и не требуются явные права на объекты, использованные в хранимой процедуре. Пользователю, под которым ваше приложение будет ходить на базу, выдают права на выполнение хранимых процедур и не выдают явно права на таблицы и т.д. В результате пользователь может совершать только действия, разрешенные в хранимой процедуре. В MS SQL ситуация немного другая - там зачастую необходимы явные права на объекты. Про Оракл не подскажу - с ним не работала.
Иногда часть данных можно "закрыть", создав view, но это скорее "позволить видеть определенные столбцы в таблице". Строк это касаться не будет (если вы не решите создавать на каждого пользователя своей базы отдельное view, что делать я Вам не советую, особенно если пользователей больше 10 ). Пользователю выдаются права на view, соответственно видит он только позволенную ему часть таблицы

Но это так, сильно общая теория.

Если это не является конфиденциальной информацией, давайте пообщаемся более предметно: что именно делается, какая задача решается, предполагаемый объем данных. Чем смогу - помогу

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (10.02.12 18:13) писал(a):
Чем смогу - помогу
Понял, благодарю. Позднее сформирую вопросы, чтоб полаконичнее и Вас сильно не загружать.

--------------------
momento mori
Момент - и в море (ц)
 
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

Гхм...
nati_vostrikova (10.02.12 18:13) писал(a):
Насколько я понимаю, Вы MS SQL собрались использовать?
U-Cesar (10.02.12 13:03) писал(a):
Предполагаю связку линукс + пострес/мускуль. Ну, и интерфейс под винду.
Прошу прощения, продолжайте, пожалуйста

--------------------
Приходи тихо, проси мало, уходи быстро.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (10.02.12 23:21) писал(a):
Гхм...


Прошу прощения, продолжайте, пожалуйста
Я не работаю в русскоговорящей стране уже довольно давно. Мне непонятен русский "перевод" названий. Линукс - еще куда ни шло, но кто такой "мускус" - я не понимаю. Давайте писать название продукта так, как оно называется в оригинале. Я же view вьюшкой не обзываю, как check constraints чеками и DB2 дибитухой. Потому что хочу, чтобы меня поняли. Прошу об ответной любезности.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (11.02.12 03:04) писал(a):
Давайте писать название продукта так, как оно называется в оригинале.
Полностью поддерживаю

Для синхронизации диалога сообщаю, что речь с высокой степенью вероятности шла о PostgreSQL и MySQL

Последний раз редактировалось R0bur; 11.02.12 в 11:55.
--------------------
Приходи тихо, проси мало, уходи быстро.
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (11.02.12 03:04) писал(a):
Давайте писать название продукта так, как оно называется в оригинале. Прошу об ответной любезности.
Хорошо, претензия принимается. Приношу извинения.
Речь идёт о:
1 - ОС linux
2 - СУБД PostgreSQL или MySQL (не решил ещё)

--------------------
momento mori
Момент - и в море (ц)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

U-Cesar (11.02.12 16:45) писал(a):
Хорошо, претензия принимается. Приношу извинения.
Речь идёт о:
1 - ОС linux
2 - СУБД PostgreSQL или MySQL (не решил ещё)
Спасибо, джентельмены.
Мой первый wild guess был, что Вы имеете в виду My SQL. Но из опыта (даже на соседней ветке такое имело место) My SQL часто путают с MS SQL. Вот отсюда и выросли "непонятки".
Непосредственно с PostgreSQL я не работала (это я так, предупреждаю), но будет шанс освоить еще одну СУБД к уже имеющимся.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (09.02.12 04:36) писал(a):
Senior DB2 DBA/ Data Architect. Сфера деятельности - банковская.
Если не секрет -- что-нибудь из продуктов Misys Solutions?

--------------------
Приходи тихо, проси мало, уходи быстро.
 
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (11.02.12 17:39) писал(a):
Если не секрет -- что-нибудь из продуктов Misys Solutions?
Не секрет. Оба раза нет. С точки зрения БД:

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 U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (11.02.12 16:54) писал(a):
Непосредственно с PostgreSQL я не работала (это я так, предупреждаю)...
Понятно.
В общем, на неделе набросаю своё видение решения задачи и буду думать.
Проблема усугубляется двумя вещами:
1 - неопределённостью с техническим заданием со стороны руководства
2 - и, как следствие, отсутствием полномочий на утрясание рабочих моментов.

Что до остального, то я сам кагбэ не "копенгаген" в СУБДах, разбираюсь "на лету".

--------------------
momento mori
Момент - и в море (ц)
 

U-Cesar U-Cesar в оффлайне

писатель
Сообщений: 2 787

U-Cesar отключил(а) отображение уровня репутации

nati_vostrikova (11.02.12 22:54) писал(a):
...AIX...
Интересно.

--------------------
momento mori
Момент - и в море (ц)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (11.02.12 22:54) писал(a):
Распределенная система (1 центральная база, несколько региональных)
А почему выбрали такое решение вместо удалённого подключения или терминального доступа (ssh, VNC, RDP) к центру? Нет возможности установить постоянный канал передачи данных и регионы работают в режиме OFF-Line по отношению к центру? Регионы генерируют большие объёмы информации, которая ими же впоследствии и обрабатывается? Во избежание утери информации в результате уничтожения центрального офиса ;-)?

--------------------
Приходи тихо, проси мало, уходи быстро.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (12.02.12 11:19) писал(a):
А почему выбрали такое решение вместо удалённого подключения или терминального доступа (ssh, VNC, RDP) к центру? Нет возможности установить постоянный канал передачи данных и регионы работают в режиме OFF-Line по отношению к центру? Регионы генерируют большие объёмы информации, которая ими же впоследствии и обрабатывается? Во избежание утери информации в результате уничтожения центрального офиса ;-)?
Регионы находятся географически на большом удалении от центра (центр - Москва, регионы - Красноярск, Новосибирск и т.д.). С постоянным каналом связи на таких расстояниях с учетом Российских реалий - напряженка.
Регионы генерируют информацию, которая этими же базами и обрабатывается. Доступа у офиса в Ростове к счету, открытому в Красноярске нет и быть не должно. Только возможность снятия денег в банкомате. В центр стекается информация со всех регионалок. Используется для учета, статистики + банкоматы. Такая архитектура хороша, потому что в одну нагруженную в режиме онлайн базу в одну и ту же таблицу не складывают информацию, которая никогда не будет использована вместе. Зачем искусственно увеличивать нагрузку на онлайн?

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (12.02.12 22:06) писал(a):
Регионы находятся географически на большом удалении от центра (центр - Москва, регионы - Красноярск, Новосибирск и т.д.).
Получается, и в часовых поясах разбежка немаленькая...

--------------------
Приходи тихо, проси мало, уходи быстро.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (12.02.12 23:26) писал(a):
Получается, и в часовых поясах разбежка немаленькая...
Есть такое (вернее, было - я в той компании больше не работаю).
Но если Вы намекаете на разницу во времени в пиковых нагрузках, то это, конечно, имеет место. Другое дело, что большая часть офисов расположена +1-2 часа от центрального. На них и приходится наибольшая нагрузка (по объему транзакций). Так что сильного распределения пиковой нагрузки в случае использования единой базы не получается.
Плюс для реализации требования "офис из одного региона не должен иметь доступ к данным счета из другого региона" пришлось бы реализовывать механизм привязки офиса к региону и клиента к региону. А это сразу ненужная нагрузка на производительность.
Проще (и в логическом и в техническом смысле) было сделать распределенную систему.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Пока все молчат, для поддержания темы проведу опрос, если никто не против.
Дано: система из 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 Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (11.02.12 22:54) писал(a):
Не секрет. Оба раза нет. С точки зрения БД:

1. DB2 V8 + Windows. Кластер. Репликация. Распределенная система (1 центральная база, несколько региональных). Data warehouse - AS400. Приложение самописное.

2. DB2 V9 + AIX. HADR. Data warehouse - mainframe + DB2 for z/OS. Приложение покупное from the box (будь оно неладно) .
Кластер средствами Windows?
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (16.02.12 23:23) писал(a):
Пока все молчат, для поддержания темы проведу опрос, если никто не против.
Дано: система из 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. Считаете ли Вы, что это все благополучно накроется в Продакшн медным тазиком (т.е. будет неработоспособным)?

П.С. свое мнение у меня имеется, просто интересно задать задачку окружающим и послушать их мнение.
Необходимо учитывать особенности DB2. Увы, но эту СУБД не знаю.
Из общих соображений.
1. Эксклюзивные блокировки на уровне таблицы/экстента/строки?
2. Есть ли возможность развести во времени онлайн и, по крайней мере, технические пакетные задания?
3. Есть ли в DB2 такое понятие как standby server? Если есть, почему бы не использовать его для выполнения резервного копирования?
4. Есть ли необходимость в постоянном обновлении статистики? Насколько меняются распределения, если сделать задержку со сбором? Есть ли такое понятие как динамическая статистика?
5. Есть ли возможность снять, например, дневную загрузку производственного сервера с последующим применением нагрузки на тестовой системе для моделирования реальной нагрузки?
6. Рассматривали ли вы вопрос создания параллельного сервера (например, с использованием GoldenGate) для пакетных заданий, чтобы разгрузить основной онлайн сервер?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (16.02.12 23:23) писал(a):
1. Считаете ли Вы, что данное изменение поведения системы связано с внедрением нового кода?
2. Считаете ли вы необходимым проведения нагрузочного тестирования всех 3 компонент данной системы (нагрузочное тестирование онлайна проводилось, тест пройден)?
3. Считаете ли Вы, что это все благополучно накроется в Продакшн медным тазиком (т.е. будет неработоспособным)?

П.С. свое мнение у меня имеется, просто интересно задать задачку окружающим и послушать их мнение.
1. Что было до введения нового кода?
2. Должно выполняться нагрузочное тестирование всей системы по крайней мере в рамках типовой нагрузки.
3. Если будет генерироваться большое количество изменений, количество журнальных файлов может резко увеличиться. Если система не позволяет на лету увеличивать количество/размер журнальных файлов (на сколько я понимаю, речь идет о циклическом буфере журналов), система "сложится".

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (17.02.12 13:19) писал(a):
Необходимо учитывать особенности DB2. Увы, но эту СУБД не знаю.
Из общих соображений.
1. Эксклюзивные блокировки на уровне таблицы/экстента/строки?
На уровне строки. Но система OLTP, следовательно, она не должна держать такого количества блокировок. Тем более что транзакция такая не одна (появляются стаями по 8-10 штук) и блокируют онлайн
2. Есть ли возможность развести во времени онлайн и, по крайней мере, технические пакетные задания?
Нет, такой возможности нет. Батчи дневные, запускаются каждые 2 часа.
3. Есть ли в DB2 такое понятие как standby server? Если есть, почему бы не использовать его для выполнения резервного копирования?
Система HADR, Standby server для непосредственно подключений недоступен.
4. Есть ли необходимость в постоянном обновлении статистики? Насколько меняются распределения, если сделать задержку со сбором? Есть ли такое понятие как динамическая статистика?
Динамическая статистика есть, но ее недостаточно. Система на пределе своих возможностей, отсутствие сбора статистики существенно бьет по производительности.
5. Есть ли возможность снять, например, дневную загрузку производственного сервера с последующим применением нагрузки на тестовой системе для моделирования реальной нагрузки?
Это я и пытаюсь заставить сделать. Мне говорят, что тестировать не надо
6. Рассматривали ли вы вопрос создания параллельного сервера (например, с использованием GoldenGate) для пакетных заданий, чтобы разгрузить основной онлайн сервер?
Не пойдет. Была бы моя архитектура, я бы рассматривала, но продукт from the box. Изменение архитектуры = потеря гарантии.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (17.02.12 13:34) писал(a):
1. Что было до введения нового кода?
Тишь, гладь и Божья благодать. Система работала, сейчас в тестовой среде с завидным постоянством падает. Транзакций с 3500+ локов не наблюдалось. Runstats хоть и замедлял систему (тестовый сервер у нас слабоват), но не клал ее с lock time out.
2. Должно выполняться нагрузочное тестирование всей системы по крайней мере в рамках типовой нагрузки.
Господа оттестировали онлайн и сказали, что все тесты сделаны. онлайн без батчей работает прекрасно. С батчами вот только падает.
3. Если будет генерироваться большое количество изменений, количество журнальных файлов может резко увеличиться.
Логично
Если система не позволяет на лету увеличивать количество/размер журнальных файлов (на сколько я понимаю, речь идет о циклическом буфере журналов), система "сложится".
Речь идет о системе архивного журналирования (которая обеспечивает возможность восстановления to point in time). Проблема в другом: Мы работаем на AIX, там под логи выделена отдельная файловая система. Строго определенного размера. Такая же ситуация с архивными логами: отдельная файловая система определенного размера. При резком росте количества логов происходит следующее: сначала забивается директория для архивных файлов (DB2 умная, она до последнего не позволяет забиться директории для активных логов, скидывая все лишнее в архивные логи), потом забивается директория для активных логов. Новые лог файл не может быть аллокирован. База ложится, пока место не появится. Место для файловой системы было выделено с учетом старой нагрузки и старого количества логов.
Этого я как раз и опасаюсь. Архивные логи чистятся ночью, вопрос только дотянем ли мы до ночи с таким резким ростом логов. Система под нагрузкой больше 2-3- часов не тестировалась.

Собственно суть проблемы: нашла коса на камень. Я говорю, что ставить это в продакшн без нагрузочного тестирования хотя бы 24 часа "в полной выкладке" (т.е. онлайн+батчи+runstats) нельзя. Архитектор вендора, который делал кэш для онлайна, говорит, что можно, якобы они батчи не зацепили своими изменениями. НО! Батчи используют те же .jar файлы, что и онлайн. К тому же поведение батчей изменилось.
А мне говорят: времени до продакшна осталось 2 недели, тестировать не будем, потом протестируем после продакшна.

Каковы Ваши прогнозы, господа? Крякнется это все в продакшене или нет?

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

На уровне строки. Но система OLTP, следовательно, она не должна держать такого количества блокировок. Тем более что транзакция такая не одна (появляются стаями по 8-10 штук) и блокируют онлайн
Не должна блокировать на длительное время. А почему такие длительные блокировки? В любой OLTP системе такие блокировки будут критическими.

Система HADR, Standby server для непосредственно подключений недоступен
.
Посмотрел определение HADR. Классический standby. Неужели нельзя на него вынести хотя бы резервное копирование данных?

Мне говорят, что тестировать не надо
Правильно говорят. Бэкапы делают только трусы.

продукт from the box. Изменение архитектуры = потеря гарантии.
Понятно.

онлайн без батчей работает прекрасно.
Ага. С минимальными изменениями данных и в пределах 2-часового интервала, когда статистика еще актуальна. А если предложить им хотя бы запустить тест без сбора статистики через сутки после существенных изменений? И сравнить и время выполнения, и планы запросов?

Система работала
Если система работала адекватно, зачем нужно было создавать систему промежуточного кэширования данных?

Логично
С похожим разбирались недавно. Увы, детализировать не могу.

Мы работаем на AIX
Ставили базу по AIX 6.1. Очень понравилась система.
К сожалению, не знаю многих особенностей операционки. Но, насколько я помню, технически возможно увеличить размер файловой системы на лету. Другое дело, есть ли такое количество доступного дискового пространства нужного типа на используемой дисковой стойке?

При резком росте количества логов происходит следующее: сначала забивается директория для архивных файлов (DB2 умная, она до последнего не позволяет забиться директории для активных логов, скидывая все лишнее в архивные логи), потом забивается директория для активных логов.
Правильно ли я понимаю, что при заполнении области архивных журналов, система продолжает работать, создавая активные журналы, но без архивных копий? Если так, то падение стойки будет означать не только падения сервера, но и возможную потерю базы со всеми вытекающими отсюда последствиями. Не знаю особенностей работы резервного сервера. Но, по логике, он должен актуализировать данные основного сервера. До тех пор, пока на него передаются архивные журналы. Т.е., получается, резервный сервер окажется с задержкой во времени.

Архивные логи чистятся ночью
При резервном копировании?

Батчи используют те же .jar файлы, что и онлайн.
Не силен в яве, но, насколько понимаю, каждый из них будет исполняться в своем пространстве/потоке. Будет увеличиваться потребление памяти java пулом.

Я говорю, что ставить это в продакшн без нагрузочного тестирования хотя бы 24 часа "в полной выкладке" (т.е. онлайн+батчи+runstats) нельзя.
Я бы сказал, что это самоубийственно. Возможные риски превышают все разумные пределы.

времени до продакшна осталось 2 недели, тестировать не будем, потом протестируем после продакшна.
Комментарии излишни.

Каковы Ваши прогнозы, господа? Крякнется это все в продакшене или нет?
Каков бы ни был исход, подход принципиально не правильный.

Последний раз редактировалось Igoroshka; 17.02.12 в 19:12.
--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (17.02.12 19:08) писал(a):
Не должна блокировать на длительное время. А почему такие длительные блокировки? В любой OLTP системе такие блокировки будут критическими.
Я про то же самое. Мне рассказывают, что это норма в OLTP. Dblbvj, у нас с оппонентом несколько разное понимание нормы и OLTP.
.
Посмотрел определение HADR. Классический standby. Неужели нельзя на него вынести хотя бы резервное копирование данных?
Вы бекапы имеете в виду? Если их, то они как раз особой проблемы не создают - бекап онлайновый, бегает ночью.
Правильно говорят. Бэкапы делают только трусы.
Ага, тормоза придумали трусы.
Понятно.
Ага. С минимальными изменениями данных и в пределах 2-часового интервала, когда статистика еще актуальна. А если предложить им хотя бы запустить тест без сбора статистики через сутки после существенных изменений? И сравнить и время выполнения, и планы запросов?
Хе-хе-хе.. мечты-мечты...
Если система работала адекватно, зачем нужно было создавать систему промежуточного кэширования данных?
Для увеличения производительности. Система в ближайшее время вырастет в 3 раза. в текущем состоянии она такой нагрузки не выдержит. вендор, создавший систему решил устранять проблему промежуточным кэшированием данных, а не переписыванием базы.
С похожим разбирались недавно. Увы, детализировать не могу.
Понимаю и сочувствую.
Ставили базу по AIX 6.1. Очень понравилась система.
К сожалению, не знаю многих особенностей операционки. Но, насколько я помню, технически возможно увеличить размер файловой системы на лету. Другое дело, есть ли такое количество доступного дискового пространства нужного типа на используемой дисковой стойке?
Возможность увеличивать размер есть, другое дело, что мы с сановскими дисками работаем, есть ли на них место лично я не знаю, я не продакшн админ. И сколько места есть. Мое предложение было оттестировать, посмотреть, не надо ли больше места, заказать его заранее. Но, видимо, тестировать будем уже на лету .

Правильно ли я понимаю, что при заполнении области архивных журналов, система продолжает работать, создавая активные журналы, но без архивных копий? Если так, то падение стойки будет означать не только падения сервера, но и возможную потерю базы со всеми вытекающими отсюда последствиями. Не знаю особенностей работы резервного сервера. Но, по логике, он должен актуализировать данные основного сервера. До тех пор, пока на него передаются архивные журналы. Т.е., получается, резервный сервер окажется с задержкой во времени.


При резервном копировании?
Давайте поясню ситуацию. Механизм такой:
вы задаете количество активных лог-файлов. Например 20. И количество вторичных лог файлов (например, 20). Это прописывается в настройках самой базы. Далее вы задаете механизм, как базе поступать со старыми лог файлами. это может быть "Оставлять в той же директории, что и активные файлы, мы сами все куда надо скопируем и почистим". Проблема этого метода - надо постоянно чистить (копировать логи например на ленту) и удалять скопированные лог-файлы. Второй механизм: "в директории оставлять только активные и вторичные файлы. Более старые при наличии возможности перемещать в архивную директорию. Чистить придется архивную директорию". Проблема та же, но чистить придется только архивную директорию, унося файлы на ленты. Если архивная директория забита, то старые лог файлы не перемещаются в архивную директорию, а остаются в активной. активная лог-директория это отдельная файловая система. постепенно она тоже забивается. Места для следующего лог-файлы не остается, база падает.
ТО есть архивная директория - это не копия активной. Каждый файл логов существует в единственном экземпляре: или в активной директории, или а архивной, или на ленте.
перемещение файлов из архивной директории на ленту происходит ночью.
Вот оттуда и мой вопрос: хватит ли нам места в активных и архивных директориях, доживем ли до ночи?
Не силен в яве, но, насколько понимаю, каждый из них будет исполняться в своем пространстве/потоке. Будет увеличиваться потребление памяти java пулом.
Не сильна в джаве, но с высокой степенью вероятности, если используется один и тот же .jar, изменения, внесенные в него для онлайна, влияют на батчи.
Я бы сказал, что это самоубийственно. Возможные риски превышают все разумные пределы.
Я бы тоже так сказала. ну что же, пожуем - увидим.
Комментарии излишни.


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

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

Мне рассказывают, что это норма в OLTP
У вас 17000 сессий. Пусть одновременных не более 10%, т.е. 1700. Пусть 2% из них борется за общие ресурсы. Итого 34 сессий по 10 с (без учета очередей, вызванных блокировками). Они хотят сказать, что система, обработка транзакции в которой из-за блокировок может длиться 340 с, имеет право считаться OLTP? А если количестов сессий возрастет, как планируется в 3 раза?

Давайте поясню ситуацию. Механизм такой:...
Я мерял меркой Оракл . Изменения заносятся в redo log (насколько я могу судить, аналоги ваших лог файлов) записями, а затем отдельным процессом (процессами) переносятся в базу данных. Обработанные redo log (архивные логи, возможно, некоторое подобие ваших вторичных логов) складируются, поскольку являются принципиальными элементами при восстановлении.

Вот оттуда и мой вопрос: хватит ли нам места в активных и архивных директориях, доживем ли до ночи?
Сейчас у вас создается 100 журнальных файлов на промышленной системе и 50 -- в тесте. Какие размеры журналов в первом и втором случаях?
Как часто журналы переключаются/ротируются? Возможно ли по статистике оценить объем журнала на транзакцию/пользователя в промышленной и тестовой системах? Сколько транзакций в секунду выполняется? Какая сдерняя длительность транзакции в обоих системах? Если транзакция длительная, она распределяется по разным логам?

Возможность увеличивать размер есть, другое дело, что мы с сановскими дисками работаем,
Я так и предполагал. При наличии технической возможности (от выделения дисков -- LUNов до покупки дополнительных полок или даже стоек) процедура выделения места достаточно проста: расширение LUNа -- расширение файловой системы.

если используется один и тот же .jar, изменения, внесенные в него для онлайна, влияют на батчи.
Насколько я понимаю, код выполнения будет один и тот же, а вот данные, с которыми работает код -- разные, и храниться в памяти будут изолировано. Мне кажется Вы должны ждать больше значительного потребления памяти.

подход мой или руководства?
Конечно же руководства. Переходить на новую систему без принципиальных тестов -- надо отдать должное умению представителей разработчиков убеждать в их непогрешимости. Ну или: "Ах, обмануть меня не трудно! Я сам обманываться рад!"

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (17.02.12 23:53) писал(a):
У вас 17000 сессий. Пусть одновременных не более 10%, т.е. 1700. Пусть 2% из них борется за общие ресурсы. Итого 34 сессий по 10 с (без учета очередей, вызванных блокировками). Они хотят сказать, что система, обработка транзакции в которой из-за блокировок может длиться 340 с, имеет право считаться OLTP? А если количестов сессий возрастет, как планируется в 3 раза?
Я, собственно, о том же. SLA - 6 секунд на любую операцию
Я мерял меркой Оракл . Изменения заносятся в redo log (насколько я могу судить, аналоги ваших лог файлов) записями, а затем отдельным процессом (процессами) переносятся в базу данных. Обработанные redo log (архивные логи, возможно, некоторое подобие ваших вторичных логов) складируются, поскольку являются принципиальными элементами при восстановлении.
Спасибо за интересный рассказ. С Ораклом я почти незнакома.
Сейчас у вас создается 100 журнальных файлов на промышленной системе и 50 -- в тесте. Какие размеры журналов в первом и втором случаях?
Как часто журналы переключаются/ротируются? Возможно ли по статистике оценить объем журнала на транзакцию/пользователя в промышленной и тестовой системах? Сколько транзакций в секунду выполняется? Какая сдерняя длительность транзакции в обоих системах? Если транзакция длительная, она распределяется по разным логам?
Транзакции по логам не распределяются. Ибо тогда появляется возможность нарушения целостности транзакции при восстановлении. Пример: транзакция занимает 2 лог файла. первый есть, второй отсутствует. Целостность транзакции при восстановлении нарушена. Транзакция должна помещаться в 1 лог. Иначе выдается ошибка. По крайней мере так ведет себя DB2 и MS SQL Server.
Размер файлов одинаковый в тесте и продакшене - 4 MB.
Я так и предполагал. При наличии технической возможности (от выделения дисков -- LUNов до покупки дополнительных полок или даже стоек) процедура выделения места достаточно проста: расширение LUNа -- расширение файловой системы.
Согласна, но и это, ИМХО, желательно сделать ДО момента "зю".

Насколько я понимаю, код выполнения будет один и тот же, а вот данные, с которыми работает код -- разные, и храниться в памяти будут изолировано. Мне кажется Вы должны ждать больше значительного потребления памяти.
Дело тут даже не в использовании памяти, а в том, что несмотря на заверения вендора, что батчи не буду затронуты изменениями в коде, это очень маловероятно, потому что используется один и тот е код. Плюс мы видим изменение поведения батчей.
Конечно же руководства. Переходить на новую систему без принципиальных тестов -- надо отдать должное умению представителей разработчиков убеждать в их непогрешимости. Ну или: "Ах, обмануть меня не трудно! Я сам обманываться рад!"
Думаю, проблема вот в чем: руководство подписало ТЗ проекта для онлайна с условием, что батчи в этот проект не входят. На проект потрачены бешеные деньги. А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.И если теперь прогнать тесты, и все накроется - будут очень неудобные вопросы. Правда, если повалить продакшн, будут очень неудобные ответы.

П.С. Вот и получилась дискуссия

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (18.02.12 01:28) писал(a):
Думаю, проблема вот в чем: руководство подписало ТЗ проекта для онлайна с условием, что батчи в этот проект не входят. На проект потрачены бешеные деньги. А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.И если теперь прогнать тесты, и все накроется - будут очень неудобные вопросы. Правда, если повалить продакшн, будут очень неудобные ответы.

П.С. Вот и получилась дискуссия
Э-эх. Везде одно и то же

В этой ситуации могу посоветовать только одно: создать план перехода, максимально учитывающий возможные проблемы. В плане прописать кто, что, когда и сколько времени делает. Определить возможные точки отката/невозврата и кто и на основе каких критериев принимает решение о продолжении переходи или возвращении на старую систему.
Отдельно -- ресурсный план, где прописать возможные требования по увеличению дискового пространства, процессорных квот (если используются LPARы).

Удачи!

---------------------
Если можно, пару слов о:
1. DB2 V8 + Windows. Кластер. Репликация. Распределенная система (1 центральная база, несколько региональных). Data warehouse - AS400. Приложение самописное.
Кластер средствами Windows?
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (18.02.12 01:28) писал(a):
А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.
Дяди лучше знают!

Если новая система затрагивает только серверную часть, я бы предложил поднять внедряемую систему на резервном оборудовании, а на входном интерфейсе поставить прокси, который бы направлял входной информационный поток как на основную, так и на внедряемую систему; клиенту выдавать ответ основной системы. Ответ внедряемой системы можно сравнивать с ответом основной (для дополнительного тестирования) или просто игнорировать.

Если затрагивается и клиентская сторона, то дело сложнее, но тоже решаемо. Суть в том, что некоторое время две системы должны работать одновременно и именно под штатной нагрузкой.

--------------------
Приходи тихо, проси мало, уходи быстро.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (18.02.12 15:39) писал(a):
Э-эх. Везде одно и то же

В этой ситуации могу посоветовать только одно: создать план перехода, максимально учитывающий возможные проблемы. В плане прописать кто, что, когда и сколько времени делает. Определить возможные точки отката/невозврата и кто и на основе каких критериев принимает решение о продолжении переходи или возвращении на старую систему.
Отдельно -- ресурсный план, где прописать возможные требования по увеличению дискового пространства, процессорных квот (если используются LPARы).

Удачи!

---------------------
Если можно, пару слов о:

Кластер средствами Windows?
Какое впечатление от работы DB2, если сравнивать Windows и AIX (с поправкой на железо, конечно)?
Кластер средствами Windows, shared disk.
Мое сугубое ИМХО, windows хорош в основном для не сильно нагруженного офисного компа, где печатают отчеты и играют в косынку. Не исключено, что я просто не умею правильно плясать вокруг него с бубном.
UNIX-оподобные системы для серверов, особенно высоконагруженных баз, мне нравятся не в пример больше.
DB2 с AIX мне нравится не в пример больше. На самом деле в деле администрирования DB2 под Windows и DB2 под UNIX почти не отличаются. Даже сертификат на них один DB2 Administrator for linux, Unix, Windows. Но по производительности на AIX работает сильно лучше. Опять же, мое ИМХО и мои наблюдения.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (19.02.12 17:54) писал(a):
Дяди лучше знают!

Если новая система затрагивает только серверную часть, я бы предложил поднять внедряемую систему на резервном оборудовании, а на входном интерфейсе поставить прокси, который бы направлял входной информационный поток как на основную, так и на внедряемую систему; клиенту выдавать ответ основной системы. Ответ внедряемой системы можно сравнивать с ответом основной (для дополнительного тестирования) или просто игнорировать.

Если затрагивается и клиентская сторона, то дело сложнее, но тоже решаемо. Суть в том, что некоторое время две системы должны работать одновременно и именно под штатной нагрузкой.
Затронута и клиентская и серверная части.

Я с Вами согласна, хоть тушкой, хоть чучелом, но следовало бы узнать, будет эта система в принципе работать в продакшене или нет ДО момента накрывания продакшена медным тазиком. А предпосылки к тазику имеются даже очень большие.
Ну ладно, мое дело прокукарекать - а там хоть не рассветай.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova: Как я понял, у вас довольно большая база данных. Если не секрет, в общих чертах, расскажите, как решаете вопрос архивного хранения информации? Не резервного, а именно архивного.

Например, "Дело N" (содержащее некоторую информацию из БД) "срок хранения 3 года". Информация за все три года хранится в основной БД? Или записи с временем создания, например, больше года (вероятность обращения к которым мала), переносите в архивную БД? Обеспечивается ли интерфейсом пользовательского ПО простой доступ к архивной информации?

--------------------
Приходи тихо, проси мало, уходи быстро.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (18.02.12 01:28) писал(a):
Я, собственно, о том же. SLA - 6 секунд на любую операцию

Спасибо за интересный рассказ. С Ораклом я почти незнакома.

Транзакции по логам не распределяются. Ибо тогда появляется возможность нарушения целостности транзакции при восстановлении. Пример: транзакция занимает 2 лог файла. первый есть, второй отсутствует. Целостность транзакции при восстановлении нарушена. Транзакция должна помещаться в 1 лог. Иначе выдается ошибка. По крайней мере так ведет себя DB2 и MS SQL Server.
Размер файлов одинаковый в тесте и продакшене - 4 MB.

Согласна, но и это, ИМХО, желательно сделать ДО момента "зю".


Дело тут даже не в использовании памяти, а в том, что несмотря на заверения вендора, что батчи не буду затронуты изменениями в коде, это очень маловероятно, потому что используется один и тот е код. Плюс мы видим изменение поведения батчей.

Думаю, проблема вот в чем: руководство подписало ТЗ проекта для онлайна с условием, что батчи в этот проект не входят. На проект потрачены бешеные деньги. А теперь выползает молоденькая архитектор, которая этому руководству напрямую не подчиняется, но которая будет за эту систему отвечать, и говорит, что вы, ребята, совсем офонарели такое чудо в продакшн ставить - продакшн повалите как тайгу на лесоповале.И если теперь прогнать тесты, и все накроется - будут очень неудобные вопросы. Правда, если повалить продакшн, будут очень неудобные ответы.

П.С. Вот и получилась дискуссия
Я бы посоветовал профайлинг до и после (на базе и на яве). А также стрес тестирование. Оперировать вероятностями тут не к месту. А "после" не значит "по причине".
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (20.02.12 00:52) писал(a):
Кластер средствами Windows, shared disk.
Мое сугубое ИМХО, windows хорош в основном для не сильно нагруженного офисного компа, где печатают отчеты и играют в косынку. Не исключено, что я просто не умею правильно плясать вокруг него с бубном.
UNIX-оподобные системы для серверов, особенно высоконагруженных баз, мне нравятся не в пример больше.
DB2 с AIX мне нравится не в пример больше. На самом деле в деле администрирования DB2 под Windows и DB2 под UNIX почти не отличаются. Даже сертификат на них один DB2 Administrator for linux, Unix, Windows. Но по производительности на AIX работает сильно лучше. Опять же, мое ИМХО и мои наблюдения.
Спасибо большое за ответ.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

funhouse (20.02.12 23:31) писал(a):
Я бы посоветовал профайлинг до и после (на базе и на яве). А также стрес тестирование. Оперировать вероятностями тут не к месту. А "после" не значит "по причине".
Что есть "стресс тестирование"? И что как не вероятности "стресс" и "профайлинг"?
Снятие и интерпретация метрик времени выполнения БД -- задача далеко не тривиальная. Особенно в высококонкурирующей за ресурсы среде. Плюс наличие оптимизатора в СУБД.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

R0bur (20.02.12 20:43) писал(a):
nati_vostrikova: Как я понял, у вас довольно большая база данных. Если не секрет, в общих чертах, расскажите, как решаете вопрос архивного хранения информации? Не резервного, а именно архивного.

Например, "Дело N" (содержащее некоторую информацию из БД) "срок хранения 3 года". Информация за все три года хранится в основной БД? Или записи с временем создания, например, больше года (вероятность обращения к которым мала), переносите в архивную БД? Обеспечивается ли интерфейсом пользовательского ПО простой доступ к архивной информации?
Ок. в общих чертах это выглядит так: есть клиент, есть его действия (транзакции например). Между таблицами, содержащими информацию о клиенте, между основной базой и архивной сделана репликация. То есть информация о клиенте содержится в обеих базах (не вся полностью, только та, которая необходима для поддержания целостности данных архивной базы). Аналогично реплицируются таблицы, содержащие статические данные. Далее информация о действиях клиента за 3 месяца содержится в активной базе. Информация о действиях клиента, которая старше 3 месяцев, выгружается из активной базы, загружается в архивную базу, после чего удаляется из активной базы. То есть в активной базе лежат действия клиента только за прошедшие 3 месяца. В архивной базе действия клиента лежат, предположим, 5 лет. Все, что старше этого "возраста", удаляется из архивной базы.
В архивной базе созданы дополнительные индексы и партишены, ибо доступ к ней осуществляется не в режиме OLTP. По условиям информация о действиях клиента, которые старше 3 месяцев, клиенту из онлайна недоступны и доступны только при запросе непосредственно сотруднику компании.
В данном случае страничка, на которой сотрудник готовит отчет для клиента, обращается к архивной базе. На нее SLA=6 секунд не распространяются.
Немного похоже на data warehouse, но в полном смысле этого слова им не является.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (21.02.12 02:54) писал(a):
Ок. в общих чертах это выглядит так...
...Немного похоже на data warehouse, но в полном смысле этого слова им не является.
Спасибо за пояснения!

--------------------
Приходи тихо, проси мало, уходи быстро.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

Igoroshka (21.02.12 01:30) писал(a):
Что есть "стресс тестирование"? И что как не вероятности "стресс" и "профайлинг"?
Снятие и интерпретация метрик времени выполнения БД -- задача далеко не тривиальная. Особенно в высококонкурирующей за ресурсы среде. Плюс наличие оптимизатора в СУБД.
Стресс тестирование - это процесс тестирования системы под пиковой(нормальной) нагрузкой. Цель тестирования выявление дедлоков мемориликов, узких мест. При обычном тестировании подобные ошибки обычно не выявляются.
Если вы о "вероятностном" характере результатов то они безусловно вероятностные но в строгом понимании этого термина а не в бытовом в котором было употреблено ране, а теория вероятностей дисциплина, как известно, точная.
Снятие и интерпретация метрик в высоконкурирующей за ресурсы среде в общем случае наверное действительно задача не тривиальная, а в конкретном не только тривиальная но и абсолбтно необходимая. Без стресс тестирования ни одна более менее сложная система в продакш не пойдет. Оптимизатор тут совершенно ни при чем.
Если вы намекаете что нужно как можно более точно имитировать реальные условия работы системы так тут нельзя не согласится, но кто говорил что будет легко.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

1. Всегда считал, что стресс тестирование -- это определение поведения системы при возникновении внештатных ситуаций: от отказа сетевого коммутатора, выхода из строя дисковой стойки до падения процесса(ов) ОС, СУБД.
2. Блокировки (в хорошей системе они, как правило, практически отсутствуют) -- всего лишь факты в биографии работы СУБД. Если они есть, при нагрузке они будут всего лишь учащаться, но не более того.
3. Утечку памяти в крупных СУБД типа Oracle (другие знаю мало) обнаружить достаточно проблематично. Явные проблемы закрываются регулярными патчами, а мелкие "успешно маскируются" множеством процессов.
4. Теорвер, как дисциплина, может быть и точная. Но ее результаты вероятностны по определению . Результат (например, время завершения выполнения запроса) как суперпозиция множества событий в СУБД с учетом вероятности их наступления, да еще в определенные моменты времени, является всего лишь оценкой с большей или меньшей погрешностью.
5. Снятие метрик, даже когда их количество переваливает за сотню, действительно, относительно несложный процесс. Сложности возникают в их интерпретации с учетом настроек системы, работы оптимизатора, выполняемых запросов, исполняемых заданий и т.д.
А запускать в промышленную эксплуатацию более-менее серьезную систему без всестороннего тестирования, в т.ч. и стрессового, таки да, неразумно.
6. Я не намекаю . Я прямо говорю, что чем тщательней определены условия работы системы, оценены перспективы, аккуратней выполнено тестирование (и документирование), тем меньше проблем будет при промышленной эксплуатации.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (22.02.12 03:40) писал(a):
Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Прежде, чем дискутировать, необходимо договориться о понятиях .
Действительно, вышла путаница. Говоря о стресс-тестировании системы предполагал проверку работы всего комплекса при различных отказах: СУБД, ОС, сервер, сеть, СХД. При этом контролируется и фиксируется поведение целевых систем -- СУБД, клиентское ПО, резервных серверов.
Мы различаем стресс-тестирование (в определении выше) и нагрузочное тестирование в определении Вики для ПО.

nati_vostrikova, а нет ли у IBM чего-то, подобного Real Application Testing у Оракл (https://blogs.oracle.com/AlejandroVa...ING-ON-10G.pdf, стр. 36-74, http://compit.by/upload/Mark_RAT.pdf)? Это был бы один из наиболее адекватных инструментов в вашем случае.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

R0bur R0bur в оффлайне

ветеран
Сообщений: 888

R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный R0bur популярный

nati_vostrikova (22.02.12 03:40) писал(a):
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Система, состоящая из набора компонентов, отличается от простого набора этих компонентов наличием новых качеств и свойств, возникающих из-за наличия связей между компонентами (по-моему, одно из первых определений системного анализа). Поэтому говорить о свойствах и поведении системы, опираясь лишь на знания о дискретных компонентах, несколько легкомысленно. Переведите на английский и передайте своему начальству. И вообще, самое время заявить, что "стае нужен новый вожак!"

P.S. Кстати, Вы уверены, что коллеги/начальство Вас не разыгрывает и Вы владеете полной информацией о предполагаемом поведении системы? Возможно, у них "козыри в рукаве"...

Последний раз редактировалось R0bur; 22.02.12 в 19:48.
--------------------
Приходи тихо, проси мало, уходи быстро.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

R0bur (22.02.12 19:43) писал(a):
...P.S. Кстати, Вы уверены, что коллеги/начальство Вас не разыгрывает и Вы владеете полной информацией о предполагаемом поведении системы? Возможно, у них "козыри в рукаве"...
Это было бы череcчур ... экстравагантно . Простой системы, обслуживающей 17 тыс. пользователей, смею предположить, весьма недешево стоит.

Последний раз редактировалось Igoroshka; 23.02.12 в 07:52.
--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

funhouse funhouse в оффлайне

графоман
Сообщений: 4 796

funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный funhouse популярный

nati_vostrikova (22.02.12 03:40) писал(a):
Господа, по-моему, неправы Вы оба
Цитирую Википедию: "Стресс-тестирование (англ. Stress Testing) — один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях.
Термин "стресс-тестирование" часто используется как синоним "нагрузочного тестирования", а также "тестирования производительности" ошибочно, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию"
"Нагрузочное тестирование (англ. Load Testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Если создаваемая нагрузка на систему превышает нормальные сценарии её использования, с целью протестировать время отклика системы на высоких или пиковых нагрузках, такое тестирование называется стресс-тестированием. В этом случае нагрузка обычно столь высока, что предсказуема ошибочная работа системы, однако не существует четкой границы между тем, когда тестирование является нагрузочным и тем, когда оно становится стресс-тестированием.".
Так что funhouse, говоря о нормальной нагрузке (или все-таки пиковой??), говорит о нагрузочном тестировании, а то, о чем говори Igoroshka - это recovery testing (сорри, не знаю, как это по-русски)
"In software testing, recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems."
А по теме дискуссии: все согласны, что хотя бы какое-то тестирование должно иметь место? Причем не для части системы (онлайн), а для всей системы целиком (онлайн + батчи + database maintenance)?
Значит так, это все термины. Я мог бы быть и более строгим в терминах. Но как говорится гуд энаф. На практике не проводится обычно и нагрузочное и стресс тестирование. Потому как оно переходит одно в другое. Не читал вики кстати но даже интерестно где они точно проведут границу. Типа 1000 запросов в минуту от 50 конкуретных пользователей это "нагрузочное" а 1001 - это уже стресовое очевидно. На практике часто бывает так проводили "нагрузочное" а оказалось "стрессовое" и когда пофиксали все узкие места, тогда да - снова нагрузочное. Детский сад, вообщем. Ну да ладно, тестеры и их теоретики - это особая каста. На практике, да, стесс тестирование может помочь тестирование например обработки ошибок в экстремальных ситациях типа "оут оф мемори". Но это на самом деле редко кого интересует, хотя и может быть важно.
Что касается - "нет мемори ликов в СУБД", вообщем скорее всего, да, не найдешь, но не факт - зависит от приложения. Но сама постановка вопроса выдает - администратора БД - который дальше БД не смотрит. А основные проблемы как раз таки создают пользователи БД которые могут "озадачить" любую БД. Ну или выявить слабые места. Например банальное отсутсвие индекса там где он необходим (но, например, "потерялся").
Вообщем стресс тестирование, мой рецепт.

Последний раз редактировалось funhouse; 23.02.12 в 00:26.
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

В крупных системах, с которыми приходится работать, "озадачить" СУБД запросами удавалось только разработчику прикладного ПО (в большинстве своем) или ДБА, так как пользователь работает только через приложение.
А "банальное отсутствие индекса" или же, наоборот, его неоправданное присутствие как раз лежит на совести разработчика и ДБА, но никак не пользователя. К слову, проверяется это весьма просто.

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (23.02.12 09:13) писал(a):
В крупных системах, с которыми приходится работать, "озадачить" СУБД запросами удавалось только разработчику прикладного ПО (в большинстве своем) или ДБА, так как пользователь работает только через приложение.
А "банальное отсутствие индекса" или же, наоборот, его неоправданное присутствие как раз лежит на совести разработчика и ДБА, но никак не пользователя. К слову, проверяется это весьма просто.
Соглашусь на 100%. В больших системах пользователь запросов не вводит. (Можно я полюбуюсь на банковскую систему, в которой пользователь вводит запрос на базу? Или в которой вдруг может сгенерироваться запрос, который базу подвесит) Запросы выполняются из приложения, и автор их - разработчик или сам ДБА, а ответственность за их работу - на ДБА. Это обязанность ДБА проверить топ 10 - 20 самых тяжелых запросов приложения и выяснить, почему они таковыми являются. И проверить план выполнения хранимок, прежде чем ставить их в продакшн. У меня ни одна хранимка без моего ревью на прод не уходит.
Потерянный индекс ловится на раз-два-три. Как и лишний индекс. И делает это ДБА исходя из плана исполнения запроса. Только не индексами едиными жива база. Например, если разработчики не знали, что такое параметризованный запрос и в динамический запрос загоняли значения параметров явно, то с индексами может все быть в порядке. Вот только сервер в основном будет заниматься компиляцией и построением плана исполнения запроса.
Кстати, мое сугубое ИМХО, ДБА отвечает за работоспособность базы. куда-то дальше ему смотреть не обязательно. ИМХО. Я рисую архитектуру данных - и архитектура остального приложения меня интересует постольку поскольку. Мне полезно знать, что батч сервер у нас на самом деле кластер, но как именно он реализован - уже не моя забота.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

nati_vostrikova nati_vostrikova в оффлайне

графоман
Сообщений: 5 568

nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный nati_vostrikova популярный

Igoroshka (22.02.12 20:08) писал(a):
Это было бы череcчур ... экстравагантно . Простой системы, обслуживающей 17 тыс. пользователей, смею предположить, весьма недешево стоит.
Вопрос тут скорее в другом: на проект кэширования потрачено пару-тройку миллионов долларов. Если остановить вывод системы в продакшн, оттестировать и увидеть, что система неработоспособна вся целиком, то вопросы будут к вендору, делавшему проект кэширования (для простоты - вендору 1). Если вывести систему в продакшн, и она там повалится, отвечать будем мы. Для заказчика мы такой же вендор как и авторы проекта кэширования, хотя при этом заказчик является нашей же дочерней структурой. Забавно, правда? Заказчик долгое время хороводился вендором 1, потом пришло руководство с вопросом "и что это было?" - так на горизонте появились мы. Естественно по старой памяти заказчик скорее спихнет вину на нас, чем на любимого вендора 1. А я как-то не хочу получать по ушам за проект, влияния на который я оказать не могу.
Политика, йошкин кот.

--------------------
- Кем это Вы себя мните?
- Не ваше дело, кем я себя мну! (с)
 

Igoroshka Igoroshka в оффлайне

графоман
Сообщений: 4 685

Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный Igoroshka популярный

nati_vostrikova (23.02.12 15:53) писал(a):
...Например, если разработчики не знали, что такое параметризованный запрос и в динамический запрос загоняли значения параметров явно, то с индексами может все быть в порядке. Вот только сервер в основном будет заниматься компиляцией и построением плана исполнения запроса...
Или пишут некое "универсальное" приложение для "всех СУБД", которое на реальной системе приводит к созданию очередей ввиду особенностей конкретной СУБД. Или расставляют везде хэши, потому что запросы выполняются с полным сканированием таблиц так как механически перенесли статистику с тестовой системы на производственную, и оптимизатор делает неправильное заключение. Или разрабатывают приложение, функционирующее на кластере, но пишут его так, будто работает на одиночном сервере, а потом удивляются, почему такие большие задержки при банальном получении очередного значения для sequence?

--------------------
Чтобы оторваться от земли надо крыльями махать. Падать в кайфе легче. (с) waspan.
Страницы: 1  2  3  4  5   из  8
Загрузка...
 
Быстрый переход
[]
Вверх
HOSTER.BY: профессиональный хостинг и регистрация доменов .BY
Более 35000 сайтов выбрали нас. Присоединяйтесь!