Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 Широкая таблица  [new]
the_moon
Member

Откуда: Германия
Сообщений: 332
Привет,

есть у нас в базе (Mainframe) широкая табличка (53 колонки). Часть из них используется редко. К примеру есть поле "Заметки" varchar(2000). Которое не для всех записей заполненно и очень разной длинны. Есть аналогичное поле с флагами. Тоже varchar(2000) всегда есть данные, но очень разной длинны (слепленные ключи из другой таблички в одну строку) и используется тоже достаточно редко.

В этой табличке хранится центральныая сущность базы, потому по этой табличке часто ищут пользователи и табличка с индексами двольно часто обновляется. С ростом данных и пользователей поиск стал притормаживать. Вопрос как все это оптимизировать.

1) Мне приходит в голову убрать из таблички все колонки, которые непосредственно в поиске не участвуют и перенести их в отдельную табличку с расширенной инфой так сказать. Почему так решил, потому, что просто чтение из таблицы без затей и лишних условий бывает длится пару секунд.

Вопрос поможет ли?

2) Еще думаю предолжить партиционировать табличку по филиалу. С базой данных работают несколько филиалов и по хорошему они работают только с со своими сущностями. Только как уговорить админов партиционировать табличку. Насколько сложно уже существующую табличку мигрировать на партиционированную?

3) Так как я не специалист, хотел спросить, может есть другие варианты?

Спасибо что прочитали до конца
17 июн 16, 17:23    [19306379]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
m&m
Guest
the_moon,

уменьшение кол-ва колонок поможет, только если много запросов типа "select *".
17 июн 16, 17:46    [19306507]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
Константин Краснов
Member

Откуда: Москва
Сообщений: 26
Здравствуйте!

the_moon
1) Мне приходит в голову убрать из таблички все колонки, которые непосредственно в поиске не участвуют и перенести их в отдельную табличку с расширенной инфой так сказать. Почему так решил, потому, что просто чтение из таблицы без затей и лишних условий бывает длится пару секунд.

Вопрос поможет ли?

При уменьшение размера записи на странице того же размера поместится больше записей. Это может способстовать увеличению коэфициента попадания записей (hit ratio) в буфферный пул, что уменьшит задержки ввода/вывода.
Также это может позволить уменьшить размер страницы (у Вас, скорее всего, 32K), что может быть предпочтительнее при случайном чтении.

Если у Вас чтение длится пару секунд, то подобные оптимизации не дадут существенного прироста производительности. Проблема в чём то другом.

the_moon
2) Еще думаю предолжить партиционировать табличку по филиалу. С базой данных работают несколько филиалов и по хорошему они работают только с со своими сущностями. Только как уговорить админов партиционировать табличку. Насколько сложно уже существующую табличку мигрировать на партиционированную?

Мигрировать достаточно просто. Вы можете создать партицированную таблицу с другим именем, скопировать в неё данные (с помощью утилит UNLOAD/LOAD, LOAD FROM CURSOR или запросом INSERT ... SELECT ...) и переименовать.
Это может дать прирост производительности, если в запросе будет предикат позволяющий выбрать раздел. Для получения выгоды, возможно, придётся переписывать запросы. Вряд ли это существенно поможет.

the_moon
3) Так как я не специалист, хотел спросить, может есть другие варианты?

Скорее всего, дело в запросе. Чтобы понять так это или нет, соберите статистику по всем таблицам, использующимся в запросе, постройте план доступа и выложите. Лучше в графическом виде с помощью IBM Data Studio.

Если запрос динамический, приведите метрики из кэша запросов. Получить их можно с помощью инструмента Query Tuner в IBM Data Studio или с помощью запроса EXPLAIN STMTCACHE ALL (предварительно запустив трассировку IFCID 318).

Какая загрузка процессора на момент выполнения запроса?
Сколько строк в таблице и средняя длина записи?
20 июн 16, 22:17    [19316513]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
knudsen
Member

Откуда: Москва
Сообщений: 311
the_moon,

А как в табличке ищут данные? только по филиалу или ещё дата там присутствует? если есть, то можно отпартиционировать по дате (год\квартал\месяц). От сортировок тоже может зависеть... план запроса вам поможет.
Сомневаюсь, но вдруг поможет всё-таки разбиение на две таблицы узкую-длинную и широкую-короткую + LEFT OUTER JOIN по индексу.
Информация вся из таблицы востребована постоянно? Может что-то "сдать в архив"?
21 июн 16, 17:06    [19319695]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
the_moon
Member

Откуда: Германия
Сообщений: 332
m&m
the_moon,

уменьшение кол-ва колонок поможет, только если много запросов типа "select *".


В каком то смысле так и есть. Для доступа к данным используется древний persistence framework в котором ява объекты маппятся на таблички в базе данных. Вернее на вьюшки вида create view as select t_a as a, t_b as b from t.

Ну и конечно когда читается или пишется объект читаются все поля таблички и апдейтятся все поля.

Много запросов которые генерируются библиотекой которые очень вычурные.
23 июн 16, 18:15    [19327579]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
the_moon
Member

Откуда: Германия
Сообщений: 332
Константин Краснов
Здравствуйте!

Если у Вас чтение длится пару секунд, то подобные оптимизации не дадут существенного прироста производительности. Проблема в чём то другом.


Может быть. Мне думается много конкурирующих записей/запросов. Табличка 350к записей, 53 колонки, средняя длина 900 байт. Несколько индексов по нескольким полям. Таблица центральная, часто актуализируется (INSERT, UPDATE) из стороннего приложения. Обычно 100 раз в минуту. Пользователи часто опрашивают под самым разным соусом и джойнами. Некоторые пользуют систему как Data Warehouse. Плюс всякие процессы, которые читают и пишут все поля обратно. По ночам старые записи удаляются. Статистика собирается по выходным.

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


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

Константин Краснов
Чтобы понять так это или нет, соберите статистику по всем таблицам, использующимся в запросе, постройте план доступа и выложите. Лучше в графическом виде с помощью IBM Data Studio.


В этом вся и беда. Я оутсорсник, пишу код клиенту. У меня нет полного доступа к базе. Могу сделать запроc из табличек приложения, да sysibm.sys... Вот и все. Есть такая же тестовая база, где есть plan_table. Есть логи приложения, где пишутся запросы которые более 1 секунды работали. Вот и все к сожелению. Меня спросили почему тормозит и что можно сделать. Я просто насобирал все, что пришло в голову, а они должны будут сами решать. Стоит всем этим заниматься или нет. У них есть свой продвинутый айтишник, у который более полный доступ к базе. Он будет разбираться.
23 июн 16, 19:26    [19327821]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2549
Начинать надо с мониторинга. Какие запросы идут вообще к этой таблицы, сколько всего времени тратится. Если оптимизировать "свои" запросы, легко по дороге угробить "чужие". Если вы "вертикально" делите таблицу - "эти поля мне нужны, а эти нет", вы себе можете чуть-чуть (!) ускорить, зато запросы с "ненужными" вам колонками становятся джойнами с соответствующими огромными последствиями. Добавочные индексы - более консервативный подход, но это и огромное влияние на скорость обновлений.

Собрав статистику (в нормальном, а не в зауженном смысле - то есть, включая сведения - какие запросы есть в наличии, что надо оптимизировать и во сколько раз, что нельзя портить более чем в столько-то раз), надо смотреть планы и т.д. Тут бы неплохо помог index adviser, но что там есть на неизвестном мэйнфрейме с неизвестной СУБД?

Простые ответы идут от непонимания. Может помочь, может не помочь, это как игральный кубик подбрасывать. А полноценное разбирательство требует много работы. Включая понимание имеющихся инструментов.
24 июн 16, 05:37    [19328963]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
m&m
Guest
the_moon,

350 тыс.записей - объем не большой.
из-за операций чтения страниц в буфер, записи из буфера тормозов не должно быть (ИМХО).
т.е. изменение структуры таблицы (разбиение, миграция в партиции) - врядли сильно поможет.
судя по общему описанию:
автор
Таблица центральная, часто актуализируется (INSERT, UPDATE) из стороннего приложения. Обычно 100 раз в минуту. Пользователи часто опрашивают под самым разным соусом и джойнами. Некоторые пользуют систему как Data Warehouse. Плюс всякие процессы, которые читают и пишут все поля обратно.

тормоза могут быть из-за ожидания блокировок.
в систем-З не разбираюсь, но, по-идее, там тоже должен быть лок-лист.
посмотрите по db2diag.log - случаются ли эскалации блокировок?
М.б. имеет смысл создать MQT и чтение данных максимально перенаправить на нее?
24 июн 16, 11:02    [19330147]     Ответить | Цитировать Сообщить модератору
 Re: Широкая таблица  [new]
Константин Краснов
Member

Откуда: Москва
Сообщений: 26
the_moon
Может быть. Мне думается много конкурирующих записей/запросов. Табличка 350к записей, 53 колонки, средняя длина 900 байт. Несколько индексов по нескольким полям. Таблица центральная, часто актуализируется (INSERT, UPDATE) из стороннего приложения. Обычно 100 раз в минуту. Пользователи часто опрашивают под самым разным соусом и джойнами. Некоторые пользуют систему как Data Warehouse. Плюс всякие процессы, которые читают и пишут все поля обратно. По ночам старые записи удаляются. Статистика собирается по выходным.

Таблица небольшая. Подобные задержки могут быть если сканируется значительная часть таблицы или есть задержки за счёт блокировок (те же INSERT, UPDATE). Вам нужно посмотреть план запроса (перед этим лучше собрать статистику по таблицам из запроса).

the_moon
Я надеюсь, что поможет поскольку все крупные филиалы в одном часовом поясе и все работают одновременно. Есть пара в других странах, но там не так много записей. Почти во всех формах поиска в приложении есть возможность выбора номера филиала, относительно легко его сделать обязательным, тем самым в поиске будет постоянно присутсвовать предикат.

Вряд ли есть смысл делать разбиение на разделы для такой небольшой таблицы. Если бы у вас было 350 млн записей, то, вероятно, стоило бы.

the_moon
В этом вся и беда. Я оутсорсник, пишу код клиенту. У меня нет полного доступа к базе. Могу сделать запроc из табличек приложения, да sysibm.sys... Вот и все. Есть такая же тестовая база, где есть plan_table. Есть логи приложения, где пишутся запросы которые более 1 секунды работали. Вот и все к сожелению. Меня спросили почему тормозит и что можно сделать. Я просто насобирал все, что пришло в голову, а они должны будут сами решать. Стоит всем этим заниматься или нет. У них есть свой продвинутый айтишник, у который более полный доступ к базе. Он будет разбираться.

Вам нужны таблицы для EXPLAIN. Это PLAN_TABLE и т.п. У Вас они уже есть. Вы уже можете построить план запроса с помощью EXPLAN и посмотреть содержимое PLAN_TABLE и других таблиц. IBM DataStudio это клиент, которые строит, по перечисленным ранее таблицам, граф.
Для получения метрик из кэша запросов в таблицу DSN_STATEMENT_CACHE_TABLE Вам понадобится дополнительная привелегия TRACE. На тестовой БД, скорее всего, её могут дать. Это позволит получить метрики необходимые для определения проблемы (DSN_STATEMENT_CACHE_TABLE)
26 июн 16, 20:17    [19337450]     Ответить | Цитировать Сообщить модератору
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить