Чтобы не плодить много постов, буду писать все найденные мною интересные ресурсы про Netezza сюда.
1. Есть замечательный блог сотрудника IBM – Андрея Выходцева. Андрей на текущий момент, наверное, лучше всех знает что такое Netezza и как ее готовить. Поэтому, если интересуетесь данной тематикой, данный блог обязателен к посещению.
2. Интересный технический блог про Netezza, расположенный на сайте наиболее известного клиента для работы с Netezza – Aginity. Что любопытно, среди авторов есть наши соотечественники (судя по именам).
3. Здесь собраны некоторые интересные советы для разработчиков по Netezza. информации не очень много, но она довольно емкая и полезная.
В первой части статьи мы рассмотрели процесс установки и проследили процесс полного обновления (refresh). Во второй части статьи хочется детально рассмотреть как происходит процесс репликации изменений. Для примера возьмем большую транзакцию содержащую только insert. Режим репликации – простой continuous mirroring один-в-один. Начинаем загрузку в реплицируемую таблицу. Генерируем данные в 8 потоков следующим скриптом.
Очевидно, что первой задачей перед счастливыми обладателями полутонны счастья (ага, Netezza в конфигурации половинки весит 560 кг), встанет наполнение ее данными. Логично рассудить, что при довольно внушительной стоимости, вряд ли ее обладатели будут ценителями эстетической красоты большего зеленого шкафа. Скорее, все-таки, перед ними стоит задача оперативной загрузи и обработки внушительных объемов информации. Значит данных в нее загрузить придется много. Основной механизм, который предполагает для этого Netezza – это External tables. Т.е. вы подключаете внешний текстовый файлик как таблицу и забираете данные из этой таблицы, вставляя их куда нужно. Очевидно, мороки с этим мероприятием довольно много. Поэтому ребята придумали утилиту nzload, которая несколько упрощает этот процесс. Но мы то с вами знаем, что настоящие ИТшники – Великие лентяи. Поэтому вспоминаем, что IBM в своем стеке продуктов имеет продукт под полным названием IBM InfoSphere Change Data Capture. Очевидное преимущество данного продукта заключается в том, что при его использовании нам не придется придумывать как выгружать данные из Oracle в текстовые файлы и как после этого загружать их в Netezza. Все можно будет сделать за пару кликов мышки.
Я нахожу забавным, что название этого блога все больше теряет актуальность. Его содержание уже давно вышло за рамки MOLAP. И сегодня оно впервые выйдет за рамки технологий Oracle. Но повод для того на мой взгляд весьма достойный. Сегодня я хочу начать писать здесь про Netezza. На текущий момент я работаю в компании КРОК и по всей видимости буду в том числе заниматься здесь практикой по Netezza.
Думаю, что все уже знают что такое Netezza – это appliance. Слово “прибор”, как переводят на русский язык слово appliance в компании IBM, мне не импонирует. Не правильные ассоциации вызывает оно, знаете ли. Песня “Снежинка” группы “Несчастный случай” приходит на ум. Так вот под appliance понимается программно-аппаратный комплекс, состоящий из предустановленной ОС с СУБД в софтовой части и массивно параллельной железки в аппаратной части. Сама железка состоит из стораджа приличного объема, двух хостов и пачки блейд-серверов. Поставляется все это удовольствие уже собранным и готовым к использованию, в чем я имел удовольствие убедиться на собственном опыте. После этого еще день уходит на прогонку всевозможных тестов, обновление FirmWare и всего прочего. После этого девайс полностью готов к работе.
Компания IBM сейчас достаточно активно развивает это направление, и мне оно тоже кажется весьма интересным и перспективным. Так как у нас в ЦОДе уже несколько недель как появился большой ящик с симпатичной зеленой дверцей, я планирую освещать здесь некоторые особенности его работы особенно меня заинтересовавшие.
Небольшая предыстория. У нашего заказчика есть сервер, на котором крутятся два инстанса. И вот мы заметили, что потихоньку начал использоваться swap. Здесь хочу описать кейс диагностики данной неприятности. Возможно, кому-нибудь пригодится. Oracle 11.2.0.2, downstream Streams репликация с 10.2.0.4, сторона apply. Все приведенные цифры пришлось немного подправить, но общая логика сохранилась.
Всем добрый день!
Сегодня отличный день чтобы написать очередную заметку. Посвящена она будет довольно популярному продукту от Oracle (теперь:) под названием GoldenGate. Установка самого GG отлично описана вот тут. Меня же заинтересовал процесс установки подсистемы Management Pack for Oracle GoldenGate (в прошлом GoldenGate Director). В ходе инсталляции этой программы, у меня возникла очень неприятная ошибка, которая как раз и побудила меня написать данный пост. Поэтому основное внимание будет уделено именно ей. Лично у меня на решение этой проблемы ушло несколько часов, поэтому я надеюсь, что смогу сэкономить вам довольно много времени в случае возникновения аналогичной проблемы. Итак.
Director состоит из двух частей. Серверной и клиентской. Клиентскую часть я использовал виндовую и с ее установкой проблем не возникло. Установить серверную часть оказалось значительно сложнее.
Наконец, выдалась свободная минутка написать.
Часто, работая с приложениями определенного типа, встречаешь стандартный набор ошибок. Встречаются они не очень часто, однако времени на поиски путей исправления требуется обычно достаточно много. Таким образом, решил, что стоит писать о часто встречающихся неочевидных проблемах хотя бы для того, чтобы потом была возможность быстро найти решение.
Итак, сегодня хотелось бы поговорить о возникшей на днях проблеме. Выглядела она следующим образом:
ORA-12801: error signaled in parallel query server P007
ORA-08103: object no longer exists
И возникала в процессе исполнения MERGE куска данных в таблицу. Около 20 млз в 160 млз. На таблице был построен набор битмап индексов. Табличное пространство ASSM.
В нашей практике данная ошибка встречается довольно часто. Oracle имеет ряд багов на эту тему.
Обычно это лечится пересозданием битмап индексов. Думаю, что как вариант можно сделать им rebuild online.
В этот раз убийство индексов не помогло. В качестве решения сработал перенос всей таблицы в другое табличное пространство. И существует два возможных предположений на счет причины возникновения проблемы.
1. В каком-то обновляемом блоке были проблемы, однако при переносе в другое ТП, они были исправлены.
2. В исходном ТП было недостаточно места. Похоже, что истинной причиной ошибки была как раз проблема со свободным пространством. Неясно, почему ошибка выглядела именно таким образом.
Вот так.
И еще несколько удобных скриптов. Стоит заметить, что все скрипты, требующие вызова CONTROL CENTER’а выполняются достаточно долго. Одним из методов их ускорения может являться (в случае деплоя или андеплоя группы маппингов) групповая процедура. Для этого необходимо при создании плана указать сразу все необходимые маппинги.
