Каждому (пользователю) свое (данное в таблице). Часть 1
Владимир Пржиялковский При работе с общей БД часто возникает необходимость обеспечить разным пользователям разное видение одних и тех же таблиц. Хочется, чтобы один пользователь при обращении к таблице видел одни данные, а другой - другие. Как это можно сделать в Oracle? Oracle - и все, сколь-нибудь долго работавшие с этой системой, прекрасно об этом знают - достаточно эклектичная система, все более отклоняющаяся по мере своего развития от единой продуманной "генеральной линии" в угоду специальным случаям. Многие вопросы находят в ней сразу несколько неравнозначных решений. Вопрос ограничения видимости данных - не исключение. Постановка задачи Возьмем стандартный демонстрационный пример из любой поставки Oracle: таблицу сотрудников SCOTT.EMP. Предположим, что организация, в которой работают сотрудники, устроена своеобразно, так что каждый пользователь Oracle, обратившись к этой таблице, может видеть в ней только перечень сотрудников из своего отдела, то есть SCOTT - только сотрудников отдела 20, ALLEN - отдела 30 и так далее.

  Анализ результатов tkprof
Источник: ln Эта статья посвящена анализу результатов работы утилиты tkprof и выявлению причин проблем производительности, о которых эти результаты свидетельствуют.   Анализ результатов tkprof Том! Я пытаюсь интерпретировать следующий результат, и не понимаю, в чем дело. В таблице TRACE - всего 220 строк. Что ты думаешь по этому поводу?******************************************************************************** select TRACE01.TYPE ,TRACE01.STATUS ,TRACE01.SEQUENCE into :b0,:b1,:b2 from TRACE TRACE01 where TRACE01.TYPE=NVL(RTRIM(:b3,' '),' ') call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 4 0.01 0.00 0 0 0 0 Execute 19012 3.10 3.56 0 0 0 0 Fetch 19012 1056.38 1517.15 0 43282981 76048 19012 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 38028 1059.49 1520.71 0 43282981 76048 19012 Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 33 (OPS$MAXBATCH) Rows Row Source Operation ------- --------------------------------------------------- 4905 TABLE ACCESS FULL TRACE Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: CHOOSE 4905 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'TRACE' ******************************************************************************** Ответ Тома Кайта Метка максимального уровня (high water mark - HWM) (максимальный размер таблицы за все время существования) очень велика (около 2275 блоков). Однажды в таблице было намного больше 220 строк. При полном просмотре (full scan) таблица просматривается вплоть до HWM. Рассмотрим пример:ops$tkyte@ORA817DEV.US.ORACLE.COM> create table t pctfree 90 pctused 10 2 as 3 select * from all_objects; Table created.

  Сколько стоит update?
Источник: ln Эта статья посвящена анализу последствий использованию одного оператора update для выполнения всех возможных изменений данных строки в клиентском приложении. На рынке есть несколько генераторов приложений, поддерживающих базовый подход к разработке "чем проще, тем лучше". Простой код легче генерировать и проще сопровождать, даже если он кажется несколько менее эффективным. Но если генератор форм всегда генерирует код для обновления каждого столбца в таблице, даже если пользователь меняет всего лишь одно поле в форме, насколько при этом растет нагрузка на сервер базы данных? Краткая история генераторов форм Было время, когда в SQL*Forms (так его тогда называли) было принято использовать единственный SQL-оператор обновления для блока. Этот оператор update обновлял (по значению rowid) каждый столбец таблицы, упоминающийся в блоке. Это казалось неплохой идеей, поскольку упрощало код и делало его более эффективным на клиенте: не нужно было решать вычислительно сложную задачу определения действиетльно измененных полей и динамически формировать SQL-оператор для обновления только соответствующих столбцов в базе данных. Потом, в районе версии Forms 4.5 (я могу ошибаться с версией - жду поправок), корпорация Oracle добавила флаг, который можно устанавливать для выбора либо одного оператора, "обновляющего все", либо динамически генерируемого оператора "обновлять только минимальный набор столбцов".

  Экспорт - импорт БД oracle большого размера
Источник: surgutnetЕвгений Воронянский Если вы читаете данную статью, то скорее всего Вас настигло несчастье. Экземпляр продуктивной БД доживает последние дни и вот вот перестанет вообще запускаться. Из RMAN-а вы восстановиться не можете, так как пользователи "наработали" достаточно большое количество данных, а архивные журналы с момента аварии безнадежно утеряны. Забегая вперед, отмечу, что с помощью ниже описываемого метода был произведен экпорт-импорт БД размером около 160GB за 18 часов. Платформа: Хост с "испорченным" экземпляром - RAM 8G, 4CPU, дисковый массив Clariion, SunOS Solaris, Oracle 8.1.7.4-64 Хост приемник - RAM 24G, 12CPU, дисковый массив Clariion, SunOS Solaris, Oracle 8.1.7.4-64.  Дополнительное программное обеспечение: ToadForOracle (Quest).  Итак, приступим:  Будем считать что для восстановления мы добавили отдельный диск для расположения на нем исполняемых файлов, а также журналов импорта/экспорта, и для того чтобы не путаться в достаточно большом количестве журналов выполнения создадим структуру дирректорий: mount /dev/dsk/c1t1d0s0 /mnt/drive mkdir /mnt/drive/exp-imp chown oracle:dba /mnt/drive/exp-imp su - oracle cd /mnt/drive/exp-imp mkdir pipe ilog elog sql  Внимание! В данной статье приводится вариант экспорта/импорта от владельца объекта.

  Использование хранимых шаблонов при настройке приложений с недоступным исходным кодом
Источник: ln В данной статье описывается один из многих аспектов использования хранимых шаблонов (stored outlines) при настройке производительности приложений, работающих с СУБД Oracle. В частности, приводится пример их использования для настройки приложений, к исходному коду которых нет доступа. Приведенный пример был проверен в Oracle 9i Release 2. Для выполнения SQL-операторов использовалась утилита SQL*Plus. В практике сопровождения довольно часто приходится сталкиваться с задачей настройки производительности приложений, доступ к коду которых не представляется возможным. А производительность приложения сильно страдает из-за нескольких SQL-операторов, включающих подсказки оптимизатору (optimizer hints). Руководствуясь этими подсказками, оптимизатор выбирает неоптимальный план выполнения SQL-оператора.

  Формирование хранимых шаблонов в Oracle 9
Источник: ln В предыдущей статье я рассматривал хранимые шаблоны и описал один механизм "обмана" системы для получения необходимого хранимого шаблона. Я также подчеркнул, что использование этого метода в Oracle 9 сопряжено с определенным риском, поскольку детальность представления информации существенно возросла. В данной статье, продолжающей ту же тему, я представлю законный способ манипулирования ххранимыми шаблонами, который можно использовать как в Oracle 8, так и в Oracle 9. Фактически эта статья основана на экспериментах, проводившихся в стандартно установленных версиях Oracle 8.1.7.0 и Oracle 9.2.0.1. Обзор Что делать, если известно, как существенно ускорить работу оператора ЯМД, добавив несколько подсказок, но нет доступа к исходному коду, в котором можно было бы вставить эти подсказки? В предыдущей статье я показал, как можно воспользоваться для этого средствами создания хранимых шаблонов (или стабилизацией плана оптимизатора) сервера. Хранимый шаблон состоит (грубо говоря) из двух компонентов - SQL-оператора, выполнение которого необходимо контролировать, и списка подсказок, которые сервер Oracle должен применять при каждой оптимизации этого оператора. Оба компонента хранятся в базе данных в схеме outln.

  Стабилизация плана оптимизатора в Oracle 8i/9i
Источник: ln Узнайте, как с помощью "хранимых шаблонов" (stored outlines) можно повысить производительность приложения, даже если нельзя менять его исходный код, систему индексации и параметры конфигурации системы... Инструментальные средства: Для упрощения экспериментов, в статье рассматривается только простой SQL- и PL/SQL-код, выполняемый в сеансе SQL*Plus. Читателю необходимы будут привилегии, которые типичным конечным пользователям обычно не предоставляют, но, в остальном, понадобится только знание основ языка SQL. Статья начинается с описания возможностей версии Oracle 8i, но затем автор переходит к Oracle 9i, в котором появилось ряд дополнительных возможностей генерации хранимых шаблонов и работы с ними. Черный ход в черный ящик Если вы - АБД, отвечающий за работу приложения стороннего производителя на базе СУБД Oracle, то, наверняка, испытывали разочарование, обнаружив в библиотечном кэше пару крайне медленно работающих и пожирающих массу ресурсов SQL-операторов, которые очень легко можно настроить, - если бы только можно было добавить пару подсказок оптимизатору в исходный код. Начиная с Oracle 8.1, вам больше не надо переписывать SQL-операторы, чтобы добавить подсказки - можно передать оптимизатору подсказки, не меняя код. Эта возможность известна как использование хранимых шаблонов (Stored Outlines) или стабилизация плана оптимизатора (Plan Stability), причем, сонвная ее идея весьма проста: вы сохраняете в базе данных информацию типа: "если встречается SQL-оператор типа XXX, то перед его выполнением надо вставить вот такие подсказки в следующих местах..." Эта возможность дает вам три потенциальных преимущества.

  Уровни изолированности транзакций
Источник: ln В ходе чтения твоих книг и ответов в этом форуме, а также руководства "Oracle Database Concepts", у меня возник ряд вопросов о транзакциях и уровнях изоляции. 1. Ты утверждаешь, что использование уровня изолированности serialazable не снижает общую производительность: http://asktom.oracle.com/pls/ask/f?p=4950:8:2084716298042783235::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:776821414494, Однако в руководстве Oracle Database Concepts, мне кажется, утверждается, что уровень изолированности serializable приводит к снижению производительности по сравнению с read committed: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21cnsis.htm#2799 Процитирую раздел "Read Committed Isolation": "Уровень изолированности чтение зафиксированного (read committed) может обеспечивать существенно более высокую степень параллелизма за счет повышения вероятности получить несогласованные результаты в некоторых транзакциях из-за неповторяемости при чтении и чтения фантомов." "Во многих высокопроизводительных средах с большой частотой транзакций требуется б о льшая пропускная способность и более быстрый отклик, чем может обеспечиваться уровнем изолированности serializable." Это что, различие в масштабах? 2. Если существенного различия производительности не наблюдается (в контексте определенного приложения, конечно), мне кажется, лучше использовать уровень изолированности serializable вместо read committed, чтобы получить повторяемость при чтении и т.д. Есть ли у тебя какие-то критерии определения того, какой уровень изолированности устанавливать? Меня интересуют, прежде всего, приложения ООТ (OLTP). Я не могу придумать причину устанавливать уровень, отличный от serializable, но хотелось бы спросить у более опытного человека. 3.

  Oracle_trace - лучшее встроенное средство диагностики
Источник: ln В сервер Oracle встроено множество диагностического кода. Часть его, например, sql_trace, хорошо описана в документации, а часть, например, представление x$trace, не документирована вовсе. Я люблю периодически посвящать некоторое время повторному анализу такого кода, чтобы узнать, насколько расширены его возможности, получили ли они официальное признание и описаны ли в документации. Недавно, работая с сервером Oracle 9i, я с удивлением обнаружил существенное расширение возможностей oracle_trace, которое произошло за последних пару релизов. Эта статья представляет собой краткое введение в oracle_trace и описание его возомжностей. Как... ? Как найти объект, являющийся источником всех событий buffer busy waits, которые можно увидеть в представлении v$waitstat? Все мы читали руководства по настройке производительности: "Если вы видите ...

  Эффективное "изменение и вставка" (update + insert = upsert)
Источник: ln Для реализации логики upsert (изменить данные, если они существуют/вставить, если их еще нет) при пакетной обработке я использую следующие подходы: попытаться выполнить вставку, а при нарушении ограничения первичного ключа обработать исключительную ситуацию и изменить соответствующие данные. попытаться изменить данные, проверить значение sql%rowcount и если оно равно 0 - вставить соответствующие данные. Сейчас появился еще оператор merge, но его сложно использовать в хранимых процедурах, когда необходимо обрабатывать строки по одной, и формируются они не обязательно по результатам запроса. Меня интересует следующее: Что эффективнее ((1) или (2)) с точки зрения объема данных повторного выполнения? Генерирует ли сервер данные повторного выполнения для изменений, затрагивающих 0 строк, и для вставок, не срабатывающих из-за нарушения ограничения? Достаточно ли эффективен оператор merge, чтобы можно было начинать его использовать, вставляя предварительно данные в глобальную временную таблицу? Можно ли использовать pl/sql-таблицу вместо временной таблицы? Можно ли применять в качестве источника данных для merge переменные PL/SQL? Ответ Тома Кайта Оптимизировать обработку можно, если знать особенности данных: Если вы уверены, что БОЛЬШИНСТВО строк будет изменяться, сначала изменяейте, а если sql%rowcount=0 - вставляйте данные. Если вы уверены, что БОЛЬШИНСТВО строк будет вставляться, вставляйте, а в случае ошибки - изменяйте существующие данные. Если не знаете точно, придется выбирать -- объем данных повторного выполнения в обоих случаях будет одинаковым. Оператор Merge - замечательный, но появился в версии 9i.

  Согласованность данных при изменении
Источник: ln Этот статья посвящена проблеме согласованности данных при изменениях в СУБД Oracle. По мотивам интересного обсуждения на сайте Тома Кайта. Я всегда исходил из предположения, что оператор типа update t set ... where ... обрабатывается следующим образом: Берется согласованный моментальный снимок таблицы на момент начала выполнения оператора Для каждой строки этого моментального снимка:  подождать снятия блокировки, если строка заблокирована другой транзакцией,  а затем изменить строку, если она удовлетворяет конструкции where. Другими словами, любые изменения, сделанные транзакциями, начавшимися и зафиксированными после начала выполнения оператора (определяется по значению SCN), невидимы для оператора, поскольку они не входят в "согласованный моментальный снимок". Следующий эксперимент (построенный на основе реальной ситуации) заставил меня задуматься об этом еще раз.

  Первичный ключ - составной или суррогатный?
Источник: ln Этот выпуск посвящен "вечной" теме выбора столбцов для первичного ключа. По мотивам случайно обнаруженного замечательного ответа Тома Кайта на вопросы, заданные в 2001-2003 годах Первичный ключ - составной или суррогатный? Том, У меня есть таблица из 3 полей, комбинация значений которых уникальна для каждой записи. Вот эти поля:Object_ID CHAR(4) Ticket_Number NUMBER Start_DateTime DATE Ни одно из этих полей никогда не будет пустым, и ни один объект в один и тот же момент времени не будет иметь такое же значение Ticket_Number. Поэтому мне кажется, что, вместо добавления нового поля, единственным назначением которого будет уникально идентифицировать строку в таблице, я могу использовать комбинацию этих трех полей. Но в руководстве PL/SQL Developer's Guide рекомендуется не использовать составные первичные ключи. Что ты думаешь по этому поводу? Надо учитывать также следующее: Мне придется вставлять эти же значения для составных внешних ключей в несколько других таблиц. Не будет ли снижена производительность при использовании составных ключей по сравнению с простым ключом, с последовательными номерами записей? Может ли быть ее причиной необходимость сравнивать также строки и даты? С другой стороны, если лучше добавить новое числовое поле для идентификации записей, как проще всего увеличивать значение этого поля при каждой вставке? Есть ли в Oracle подобие типа данных autonumber MS Access? Ответ Тома Кайта Если требуется, чтобы "эти три поля уникально идентифицировали запись в любом случае", придется задавать по ним ограничение уникальности (UNIQUE CONSTRAINT) в любом случае.

  Системная информация в индексах
Источник: ln Эта статья посвящена обсуждению структуры записей в индексах (помните, я собирался часть выпусков посвящать индексам ;). По мотивам ответа Тома Кайта на вопрос, заданный 14 июня 2003 года. Системная информация в индексах Том, После анализа индекса (analyze ... validate) я поделил LF_ROWS_LEN на LF_ROWS и обнаружил значение на 12 байтов больше, чем длина ключа. Я ожидал увеличения только на 6 байтов - размер rowid, а откуда взялись другие 6 байтов? Может, я неправильно считаю?SQL> analyze index IDX_TBLACCOUNT validate structure; Index analyzed SQL> select * from index_stats; HEIGHT 3 BLOCKS 18056 NAME IDX_TBLACCOUNT PARTITION_NAME LF_ROWS 5796880 LF_BLKS 16868 LF_ROWS_LEN 75359440 LF_BLK_LEN 7996 BR_ROWS 16867 BR_BLKS 57 BR_ROWS_LEN 237396 BR_BLK_LEN 8028 DEL_LF_ROWS 7655 DEL_LF_ROWS_LEN 99515 DISTINCT_KEYS 20 MOST_REPEATED_KEY 4228703 BTREE_SPACE 135334124 USED_SPACE 75596836 PCT_USED 56 ROWS_PER_KEY 289844 BLKS_GETS_PER_ACCESS 144925.5 PRE_ROWS 0 PRE_ROWS_LEN 0 LF_ROWS_LEN/LF_ROWS = 75359440/5796880 = 13 Длина столбца - 1 байт (varchar2(1)).SQL> select * from user_ind_columns where index_name = 'IDX_TBLACCOUNT'; INDEX_NAME IDX_TBLACCOUNT TABLE_NAME TBLACCOUNT COLUMN_NAME AC_STATUS COLUMN_POSITION 1 COLUMN_LENGTH 1 DESCEND ASC SQL> select * from user_tab_columns where table_name='TBLACCOUNT' and column_name='AC_STATUS'; TABLE_NAME TBLACCOUNT COLUMN_NAME AC_STATUS DATA_TYPE VARCHAR2 DATA_TYPE_MOD DATA_TYPE_OWNER DATA_LENGTH 1 DATA_PRECISION DATA_SCALE NULLABLE Y COLUMN_ID 67 DEFAULT_LENGTH DATA_DEFAULT NUM_DISTINCT 17 LOW_VALUE 30 HIGH_VALUE 74 DENSITY 0.05882352 NUM_NULLS 0 NUM_BUCKETS 1 LAST_ANALYZED 6/14/2003 SAMPLE_SIZE 235526 CHARACTER_SET_NAME CHAR_CS CHAR_COL_DECL_LENGTH 1 GLOBAL_STATS NO USER_STATS NO AVG_COL_LEN 1 Анализирую другой индекс, по той же таблице, и снова получаю 12 дополнительных байтов:SQL> analyze index idx_tblaccount_stssch validate structure; Index analyzed SQL> select * from index_stats; HEIGHT 3 BLOCKS 18845 NAME IDX_TBLACCOUNT_STSSCH PARTITION_NAME LF_ROWS 5794493 LF_BLKS 17096 LF_ROWS_LEN 121620457 LF_BLK_LEN 7996 BR_ROWS 17095 BR_BLKS 53 BR_ROWS_LEN 390029 BR_BLK_LEN 8028 DEL_LF_ROWS 5268 DEL_LF_ROWS_LEN 110621 DISTINCT_KEYS 22291 MOST_REPEATED_KEY 553444 BTREE_SPACE 137125100 USED_SPACE 122010486 PCT_USED 89 ROWS_PER_KEY 259.94764703 BLKS_GETS_PER_ACCESS 133.473823516217 PRE_ROWS 0 PRE_ROWS_LEN 0 LF_ROWS_LEN/LF_ROWS = 121620457/5794493 = 20.99 (у нас 12880 строк со значениями NULL в первом столбце) Получаем снова DATE (7 байтов) + разделитель? - прокомментируй, пожалуйста, (1 байт) + varchar2(1) (1 байт) = 9 байтов. 12 байтов использовано системой для своих целей.SQL> select * from user_tab_columns where table_name='TBLACCOUNT' and column_name='AC_SCHEDULETIME'; TABLE_NAME TBLACCOUNT COLUMN_NAME AC.

  USING - ключевое слово PL/SQL в версии 9i
Источник: ln Эта статья посвящена двум особенностям работы PL/SQL-машины, которая в версиях 9.x объединена с SQL-машиной. Интересные особенности, которые могут всплыть при переносе программного обеспечения на новую версию сервера Oracle... По мотивам ответа Тома Кайта на вопросы, заданные 15 июня 2003 года. USING - ключевое слово PL/SQL! Том, Я хотел бы задать два вопроса, которые меня сильно сбивают с толку. Первый вопрос: Один из разработчиков написал следующий код в Oracle 8.1.7.3:create table auxtab as select from dual; create or replace procedure p_insert_auxtab as begin insert into auxtab using (select * from dual); commit; end; / Procedure created. SQL> show errors No errors. При попытке выполнения тех же действий в версии 9.2.0.3.0 получаем сообщение об ошибке:create table auxtab as select from dual; create or replace procedure p_insert_auxtab as begin insert into auxtab using (select * from dual); commit; end; / Warning: Procedure created with compilation errors.

  Мониторинг использования индексов в планах запросов в Oracle 10g
Источник: habrahabr Для мониторинга использования индексов Oracle предлагает простой способ - включить мониторинг индекса и выключитьпо завершению значимого для данного индекса периода. Описание на сайте Oracle тут. В результате в представлении V$OBJECT_USAGE вы можете увидеть ответ "Yes" или "No".  Но что делать если: - Вы уже знаете что индекс используется,  - популяция запросов уже настолько велика что проанализировать их на предмет использования запросами не представляется возможным - Вам нужны доп. сведения о выполнении запросов  Ответ вполне очевиден - нужно проводить мониторинг текущей работы сервера за тот период который для вас является вполне приемлемым для оценки (календарный месяц например, когда все основные операции осуществляются).  Для этого можно использовать данные которые собирает AWR, пример такого использования описан в статье "ORACLE INDEX USAGE TRACKING".  Но и тут не все так хорошо - вы зависите как часто снимаются снимки базы и какой период обновления снимков (т.е.

  Практическое использование средств FGAC
Источник: ln Том, Мы собираемся использовать возможности создания виртуальной приватной базы данных (VPD) сервера Oracle для уже работающей производственной системы оперативной обработки транзакций (ООТ). Идея в том, чтобы возможности системы могли одновременно использовать примерно 40-50 разных компаний. В каждую таблицу приложения добавляется новый столбец, например, COMP_ID. Теперь вопрос: (я знаю о твоем мнении в отношении использования индексов на основе битовых карт в системах ООТ) Не стоит ли использовать индексы на основе битовых карт по столбцам COMP_ID (VPD), просто потому, что количество различных значений в них весьма невелико? Ответ Тома Кайта НЕТ! Индексы на основе битовых карт никогда, ни при каких обстоятельствах не подходят для систем ООТ. Столбец COMP_ID станет атрибутом, который будет добавлен к существующим индексам -- сам столбец COMP_ID индексировать не нужно. Пусть имеется таблица emp:create table emp ( empno number, ename varchar2(30), job varchar2(10) ); И выполнены следующие операторы:alter table emp add constraint emp_pk primary key(empno); create index emp_ename_idx on emp( ename ); Теперь, вы добавляете столбец comp_id и выполняете операторы:alter table emp add constraint emp_pk primary key(EMPNO,COMP_ID); create index emp_ename_idx on emp(ename, COMP_ID); поскольку запрос, который имел вид:select * from emp where empno = :x; теперь будет эквивалентен:select * from emp where empno = :x and comp_id = sys_context(...); Запрос:select * from emp where ename = :x будет изменен аналогично... Вопрос читателя от 26 мая 2003 года Нет ли смысла фрагментировать таблицу по столбцу COMP_ID? Ответ Тома Кайта Конечно, можно и фрагментировать.

  Ускорение вставки
Источник: ln Том, Я бы хотел знать, как лучше всего выполнить следующие вставки. У меня есть таблицы t1, t2, t3 и x1, x2 и x3:В таблице t1 - примерно 400000 строкВ таблице t2 - примерно 1000000 строкВ таблице t3 - примерно 200000 строк Таблицы x1, x2, x3 первоначально пусты - данные добавляются в них каждый месяц. Сейчас для добавления данных я использую 3 вложенных цикла FOR. Основным является внешний цикл, в котором выбираются все записи из таблицы t1 и вставляются в x1. Первичный ключ таблицы x1 берется из последовательности с помощью триггера, срабатывающего перед вставкой. Значение последовательности возвращается в переменную с помощью конструкции returning into. Следующий вложенный цикл выбирает все записи из таблицы t2, у которых значение в столбце id соответствует значению id (первичному ключу) из x1, и вставляет их в таблицу x2 (снова генерируя первичный ключ в триггере и возвращая его в переменную).

  Снова аналитические функции
Источник: ln Балансировка нагрузки на сотрудников - снова аналитические функции Том, У меня возникла следующая проблема с оператором update: Есть таблица кредитов (loan):state_cd, user_id, status_cd, ... И таблица user_state_served:user_id, state_cd, last_asgnmt_dt Хотелось бы распределить кредиты равномерно среди сотрудников, имеющих право работать в соответствующем штате. Для этого я изменяю last_asgnmt_dt = sysdate и беру в качестве следующего ответственного за кредит user_id с min(last_asgnmt_dt). Однако после первоначального распределения нагрузка сотрудников может оказаться разной, в зависимости от количества кредитов, выданных в штате. Как можно было бы взять среднее количество кредитов в штате и поровну распределить их между сотрудниками? Например, в штате TX выдано 400 кредитов. Этим штатом сейчас занимается 4 сотрудника, нагрузка среди которых распределена так:emp1: 150 emp2: 50 emp3: 75 emp4: 0 нераспределенные: 125. Я хочу поровну поделить все активные кредиты между 4 сотрудниками.

  История изменений по иерархическим данным (workspace management)
Источник: ln Том, Мой вопрос касается таблиц, связанных отношением "главная-подчиненная", и хранения данных об изменениях в этих таблицах. Для ведения финансовой отчетности мы храним несколько иерархий отделов в одной таблице - это обеспечивает синхронизацию. Таблицы имеют следующий вид:create table t1 ( parent_id number, child_id number ) create table t2 ( object_id number, object_name varchar2(100), другие атрибуты ... ) Главная и подчиненная таблицы связаны внешним ключом. Отдел может быть подчиненным для нескольких отделов (в разных иерархиях). Если главный отдел используется в нескольких иерархиях, у него должны быть одни и те же подчиненные. Теперь вопрос: Хотелось бы отслеживать историю всех изменений в иерархиях.

  Изменение соединения
Источник: ln Эта статья посвящена "хитрым" операторам UPDATE, изменяющим данные в одной таблице на основе данных из другой. Попутно обсуждаются причины возникновения ошибки ORA-01779 при выполнении таких действий путем изменения соединения. По мотивам очередного ответа Тома Кайта. Оператор UPDATE и NULL-значения Том, При изменении столбца с помощью оператора update, значение некоторых записей (которые не надо менять) изменяется на NULL. Я использую следующий оператор:update table name B set columnname = ( select value from lookup O where B.keyname = O.keyname and O.Othercolumn = Other_value); В результате выполняются все необходимые изменения, но изменяются и записи, которые не надо менять: они получают значения Null. Можно ли этого избежать, поскольку нам надо часто изменять записи, но не все сразу. Нет ли способа изменить только те записи, которые нужно, и не сбросить значения в других записях в Null? Ответ Тома Кайта Есть как минимум 2 способа правильно выполнить такого рода коррелированное изменение.

  Выбор промежуточных записей из результирующего множества
Источник: ln Эта статья посвящена выбору записей из результирующего множества по частям. Например, для размещения на Web-страницах. Очередной выпуск по мотивам ответов Тома Кайт на вопросы посетителей его сайта. Кстати, всем интересующимся хочу сообщить, что сегодня перевод второй части книги Тома Кайта "Expert one-on-one: Oracle" закончен. Последние файлы приложений сегодня утром отправлены в издательство... Как выдавать результат постранично? Я хотел бы выбирать данные после соединения трех таблиц и сортировки по некоторому полю. Поскольку этот запрос возвращает примерно 100 записей, я хотел бы разбить результирующее множество на 4 части, по 25 записей каждая.

  Особенности использования таблиц, организованных по индексу
Источник: ln В этом выпуске мы рассмотрим некоторые аспекты использования таблиц, организованных по индексу (IOT). Повторное использование пространства в таблицах, организованных по индексу Меня интересует, как повторно использовать пространство в таблице, организованной по индексу (Index Organized Table - IOT) после удаления существенного количества строк. При работе с обычной таблицей после удаления множества строк я пересоздаю индексы, чтобы в индексных блоках не было пропусков, поскольку мы знаем, что это пустое место в индексах не будет использоваться повторно (в отличие от блоков таблиц, где это освободившееся место используется повторно, после того, как будет преодолен порог PCTUSED в блоке). Итак, что же можно сделать с таблицей, организованной по индексу, чтобы предотвратить ее постоянный рост, даже после удаления множества строк? Ответ Тома Кайта Ответ на этот вопрос, на самом деле, достаточно интересный - Oracle8i Release 8.1 позволяет выполнить два новых действия, которые делают ответ интересным: оперативное пересоздание индексов; перенос таблицы. Поскольку таблица, организованная по индексу, - это просто индекс... Мы, фактически, можем пересоздать индекс путем переноса таблицы "на ходу" (т.е. пока происходит пересоздание пользователи изменяют данные таблицы...) Вот пример:ops$tkyte@dev8i> create table demo_iot 2 ( object_id int primary key, 3 oname varchar2(30), 4 owner varchar2(30), 5 status varchar2(30) ) 6 organization index; Table created.

  Статистическая информация уровня сегмента в событии 10046 Oracle 9.2
Источник: ln Введение В версии 9.2 в Oracle добавилась возможность получать "статистическую информацию уровня сегмента". К словарю данных было добавлено несколько представлений v$, и для сбора соответствующей информации можно избирательно включать сбор статистики на уровне сегмента. Однако при выполнении трассировки с помощью события 10046 эта статистическая информация тоже выдается. По-видимому, хотя я и не нашел еще никакой определенной информации об этом, она появилась в наборе исправлений 9.2.0.2. Поскольку это - статистическая информация "источника строк" ("row source" statistics), она будет входить в строки STAT. Дополнительная информация - часть информации об операции доступа к источнику строк, а именно - поле "op=". В этой статье мы разберемся, как найти эту информацию и как ее можно использовать.

  UNUSED COLUMNS и дисковое пространство
Источник: oracle На написание этого небольшого материала автора подтолкнул очередной вопрос разработчиков о том, каково влияние операции SET UNUSED COLUMN на последующий расход дискового пространства. Вопрос вовсе не праздный, если учесть современные объемы данных и время, потребное для их реорганизации. Поэтому автор решил продемонстрировать, а что же собственно происходит, когда выполняется операция SET UNUSED COLUMN. Начнем с того, что весьма распространено заблуждение, гласящее, что unused column удаляется из словаря данных. Разумеется, это не так, и существуют представления ..._TAB_COLS, позволяющие увидеть, что происходит с полями, помеченными как UNUSED.SQL> CREATE TABLE table1(x int primary key); Table created. SQL> CREATE TABLE table2(x int, y int default 0, 2 constraint y_c1 primary key(y), 3 constraint y_c2 foreign key(y) references table1(x), 4 constraint y_c3 check (y > 0)); Table created. SQL> col data_default format a10 SQL> col nullable format a10 SQL> col column_name format a30 SQL> col hidden_column format a10 SQL> select column_name, data_default, nullable, hidden_column 2 from user_tab_cols where table_name = 'TABLE2'; COLUMN_NAME DATA_DEFAU NULLABLE HIDDEN_COL ------------------------------ ---------- ---------- ---------- X Y NO Y 0 N NO SQL> select constraint_name, constraint_type from user_constraints 2 where table_name = 'TABLE2'; CONSTRAINT_NAME C ------------------------------ - Y_C3 C Y_C1 P Y_C2 R SQL> alter table table2 set unused column y; Table altered.

  Корпорация Microsoft представляет вторую редакцию Microsoft SQL Server 2008 R2
Источник: PCWeek Анонсируя для российской общественности вторую редакцию Microsoft SQL Server 2008 R2, директор по маркетингу платформы приложений Microsoft в Восточной и Центральной Европе Тара Сеппа заявила, что 80% появившихся в ней новшеств имеют самое непосредственное отношение к бизнес-аналитике. Microsoft позиционирует программу не как СУБД, а как платформу управления данными, призванную помочь заказчикам извлекать из них ценную информацию, независимо от того, где эти данные находятся - на ПК, в дата-центре или на "облаке". Сегодня в составе указанной платформы наряду с собственно реляционной СУБД присутствует целый ряд служб: для генерации отчетов (Reporting Services), бизнес-анализа (Analysis Services), интеграции информации из разнородных источников (Integration Services), управления мастер-данными (Master Data Services). По сути, это полноценная платформа Business Intelligence, предлагаемая многими вендорами в виде самостоятельного продукта. К этой же сфере следует отнести включенную в SQL Server R2 технологию Power Pivot для быстрого анализа больших массивов данных (сотни миллионов записей) непосредственно в оперативной памяти настольного ПК (надстройка над Microsoft Office Excel) и модуль StreamInsight - средство анализа данных в потоке, обычно относящееся к категории CEP (Complex Event Processing). В отличие от классических BI-систем, в которых данные из множества источников сначала загружаются в хранилище и только после этого становятся доступны для исследования, технология StreamInsight дает возможность начать обработку данных уже в момент их поступления из того или иного источника: входящие данные пропускаются через систему логических фильтров, позволяющих выделить только значимую для конкретного бизнес-процесса информацию. В зависимости от поставленной задачи эта значимая информация может быть дополнительно обработана или сохранена, но более важно то, что избыточные данные, присутствующие в потоке, просто отбрасываются, а это сулит существенную экономию ресурсов системы хранения.

  Rapid SQL XE3
  Продукт Rapid SQL XE3 от компании Embarcadero помогает разработчикам и администраторам БД очень быстро создавать высокопроизводительный SQL-код. С обеспечением поддержки всех основных платформ управления базами данных из единого интерфейса, команды разработчиков могут создавать приложения, отвечающие требованиям стандарта, на основе единой мощной гетерогенной инструментальной среды SQL IDE. Многофункциональная среда разработки упрощает написание SQL-скриптов, построение запросов, управление объектами и проектами и контроль версий кода для динамически изменяющихся баз данных или автономных хранилищ исходного кода. Интуитивно понятный инструментарий редактирования, отладки и оптимизации SQL-кода помогает создавать высокопроизводительный SQL-код. Продукт  Rapid SQL XE3, относящийся к последнему поколению семейства продуктов Rapid SQL, позволяет разрабатывать приложения для всех основных платформ СУБД и содержит в своем составе приложение Embarcadero® AppWave™, обеспечивающее централизованное управление лицензиями, контроль использования инструментария и предоставляющего возможность развертывания приложения "с нуля". С версией Rapid SQL XE3 Вы получаете: Поддержку всех семи платформ управления БД в рамках единой, доступной по цене, лицензии Выход на мировой уровень с полной поддержкой символов Unicode и улучшенной поддержкой мировых валют Три новых средства фильтрации объектов Предупреждения "на лету" о синтаксических ошибках, семантическая проверка правильности выражений и синтаксический анализ  SQL-кода Полный сквозной поиск объектов в SQL-операторах Завершение написания кода с динамическими "прогонами" Быстрый экспорт и импорт информации в отношении зарегистрированных источников данных Поддержка InterBase® и Firebird При разработке кросс-платформенных приложений графические редакторы объектов любого типа из состава Rapid SQL позволяют без труда переходить от схемы управления SQL Server или Sybase к схеме управления Oracle и наоборот. Продукт содержит полную базовую информацию о системном каталоге СУБД, синтаксисе и правилах изменения.

  Веб-семинар "All-Access: решение задач ИТ-образования в вузах" от Embarcadero
Компания Embarcadero приглашает Вас 18 мая в 12:00 по московскому времени принять участие в веб-семинаре  "All-Access: решение задач ИТ-образования в вузах". Основной задачей преподавания IT-дисциплин в вузе является охват широкого спектра технологий, включающей разработку приложений, Web-технологии, а также создание и администрирование баз данных. Это подразумевает использование в образовательном процессе множество разнообразных программ как для демонстрации принципов и методов работы в области программной инженерии, так и для выработки практических навыков у студентов. Подбор соответствующего ПО может стать сложной и дорогостоящей задачей для преподавателей из-за многообразия подходов и технологий, а также трудоемкой в плане установки и сопровождения конкретных продуктов. Комплексный набор продуктов Embarcadero All-Access призван помочь вузам в решении вопросов обеспечения образовательного процесса разнообразными средствами разработки программных продуктов и баз данных. Использование All-Access в рамках вуза позволяет охватить широкий спектр технологий и языков в области программирования, включая Object Pascal, C++, Java, .NET, PHP, HTML. Продукты All-Access, ориентированные на проектирование, реализацию и сопровождение баз данных, являются мультиплатформенными, т.е.

  Компания Embarcadero анонсировала новые продукты XE для работы с базами данных
Источник: CNews Компания Embarcadero Technologies, поставщик инструментов для разработки приложений и работы с базами данных, анонсировала новые редакции основных продуктов для баз данных под общим названием XE. До появления новой линейки XE специалистам по работе с базами данных приходилось выбирать один из двух вариантов: либо использовать простые мультиплатформенные средства на основе ODBC/JDBC, обеспечивающие лишь базовые возможности, либо работать с множеством программных продуктов, каждый из которых поддерживал только одну платформу и приобретался у производителей баз данных или сторонних производителей. Новые средства Embarcadero XE имеют встроенные механизмы для полной поддержки всех основных баз данных. С помощью любого из таких средств пользователи могут работать как в одно-, так и в многоплатформенной среде. Благодаря поддержке всех баз данных снижаются расходы на лицензирование и эксплуатацию решений, а также на обучение персонала, утверждают в Embarcadero. "ИТ-среды становятся все более динамичными, часто в условиях ограниченного бюджета. Специалисты по управлению базами данных вынуждены считаться с этим, - отметил Майкл Свинделл, старший вице-президент по маркетингу и продуктам Embarcadero.

  Microsoft представила новую ERP-систему в России
Источник: CNews Корпорация Microsoft объявила о выходе локализованной российской версии Microsoft Dynamics NAV 2009 SP1 (ранее - Navision). Одним из главных улучшений разработчики называют ролевой интерфейс (RoleTailored), который включает в себя 21 типовую должность, наиболее часто встречающуюся в компаниях: например, главный бухгалтер, финансовый директор, директор по производству, руководитель компании и другие. Работая с системой, каждый из них будет видеть лишь информацию, необходимую для выполнения своих обязанностей. К другим важным функциям Microsoft Dynamics Nav 2009 разработчики относят новые возможности бизнес-анализа: инструменты, основанные на функционале Microsoft SQL Server, позволяют в автоматическом режиме детализировать отдельные показатели, генерировать отчеты, выявлять тренды и осуществлять мониторинг основных показателей эффективности бизнеса. Разработчики также отмечают наличие улучшенных веб-сервисов: они позволяют клиентам и партнерам объединять данные и логику из системы с другими приложениями, чтобы поддерживать различные сценарии. На мировом рынке Nav 2009 была анонсирована еще в ноябре 2008 г. Такой большой временной разрыв между появлением международной и российской версий в компании объясняют тем, что локализация продукта в соответствии с российскими налоговыми, бухгалтерскими, кадровыми и финансовыми реалиями требует значительных трудозатрат.

  Oracle совершенствует Oracle® Business Intelligence Applications
Источник: Пресс-центр Oracle Корпорация Oracle объявила о выпуске решения Oracle® Business Intelligence (BI) Applications Release 7.9.6.2, которое позволяет организациям получать большую отдачу от своих корпоративных приложений. В новой версии расширена интеграция с Oracle"s JD Edwards EnterpriseOne и обновлены модули Oracle Project Analytics и Oracle Procurement and Spend Analytics. Кроме того, решение сертифицировано для использования с более обширным спектром программного обеспечения Oracle и других поставщиков. Эти усовершенствования и сертификации позволят организациям повышать окупаемость ИТ-инвестиций и получать важнейшие знания о корпоративных операциях. "Oracle BI Applications помогает ведущим организациям получать полное, основанное на фактах понимание бизнес-операций, - отметил Поль Родвик (Paul Rodwick), вице-президент по развитию продуктов Oracle Business Intelligence. - Новая версия, с поддержкой дополнительных платформ и расширенными возможностями управления важнейшими бизнес-функциями, позволит организациям повышать прозрачность бизнеса, рационализировать процессы закупок и совершенствовать движение денежных средств для максимального повышения эффективности бизнеса". Комплекс Oracle BI Applications, входящий в состав семейства Oracle Fusion Middleware, включает полнофункциональные, готовые к развертыванию аналитические продукты для приложений Oracle и других поставщиков, позволяющие компаниям оперативно принимать обоснованные решения и обеспечивать повышение эффективности работы в масштабе всего предприятия.