среда, 31 декабря 2014 г.

воскресенье, 29 июня 2014 г.

Неочевидные вопросы сертификации 1Z0-047 Oracle Database SQL Expert

Продолжение. Новые вопросы с сентября 2014
  1. Нельзя писать алиас у колонки в select по которой происходит join в using (или * с алиасом таблицы). Это же относится к natural соединениям.
    SELECT key
    FROM A FULL JOIN B
    USING (key)
    
  2. Вставка в несколько таблиц
    * INSERT ALL - может быть без WHEN
    * INSERT ALL - поумолчанию
    * INSERT FIRST - при совпадении WHEN, остальные не просматриваются
    * INSERT ALL - просматриваются все ветвления WHEN
    * Может быть несколько INTO в одном WHEN
    * Нельзя использовать sequence в SELECT запросе множественном INSERT (но можно в VALUES)
    INSERT [ALL|FIRST]
     WHEN <..> THEN
      INTO A (a1,a2) VALUES(b1,b2)
     WHEN <..> THEN
      INTO C (c1,c2) VALUES(b2,b1)
     ELSE
      INTO D (d1,d2) VALUES(b1,b2)
    SELECT
     b1, b2, b3 FROM B
    
  3. MERGE dml операция:
    * Преимущество - один проход
    * D/I/U - возможные операции
    * WHERE можно писать только по таблице из USING
    MERGE INTO <..>
    USING A
      <..>
    WHEN MATHED THEN UPDATE SET <..>
    [WHERE <..>]
    
  4. WHERE выполняется до SET.
    Это значит, что в SET можно писать невалидные значения, если WHERE их отсечет.
  5. AND имеет больший приоритет, чем OR
  6. Арифметические операции имеют больший приоритет, чем SQL операторы сравнения
  7. FROM необязателен в DELETE
  8. CLOB, BLOB, TIMESTAMP WITH TIMEZONE (далее TS WITH TZ) - нельзя использовать в PK
    , а TS WITH LOCAL TZ - можно
  9. Размеры полей:
    * CHAR -> CHAR(1)
    * INTERVAL DAY -> INTERVAL DAY(2)
    * NUMBER(2,-3) - округлит! (не обрежет) до 3 знака перед запятой
    * VARCHAR - обязательно указывать размерность
    * VARCHAR(1 CHAR), если база в cp1251 - это 1 байт, если UTF8 , то от 2 байт
  10. UNION, MINUS, INTERSECT - set операторы
    Сортировка в них возможна только по алиасу или позиции в самом конце.
  11. Допускается только двойное вложение агрегирующих функций (3ий нельзя)
    MAX(SUM(<..>))
  12. Типы соединений:
    * cartesian -> cross
    * nonequijoin -> < , >
    * full -> outer
    * inner -> natural
  13. FK можно создавать по полям:
    * Одного типа, но разных разных размерностей
    * FK может указывать на PK и на UNIQUE index поля
  14. UNUSED поле - поле аналогично дропнутому, но физически из таблицы не вычищено:
    SET UNUSED COUMN <..>; --помечаем неиспользуемым
    ALTER TABLE T DROP UNUSED COUMNS; --физическое удаление неиспользуемых колонок
    
  15. По V$ представлениям нельзя делать запросы, т.к. их структура может меняться со временем.
    Если же в этом есть необходимость, то нужно сперва создать копию.
  16. Нет отдельных прав на создание FK, constraints, index
    Такие права даются вместа с правами на таблицу.
  17. Non-schema objects - это users, roles, public synonims
  18. Допускается сравнение systimestamp и date типов
  19. Если в CREATE SEQUENCE задана опция CYCLE, то MAXVALUE может быть отрицательным (т.к. START тоже может быть отрицательным)
  20. Нельзя создавать NOT NULL constraint отдельно от создания таблицы (alter)
  21. UNIQUE в SELECT аналогичен DISTINCT
  22. ROWNUM нельзя использовать с * без алиса
    SELECT ROWNUM, * --нельзя
    
  23. * NULL поля при ASC сортировке идут последними
    * при DESC первыми
    Можно указать принудительно:
    ORDER BY <..> nulls last[first]
  24. При выборке из TS WITH LOCAL TZ к дате вставки добавляется разность между зоной вставки и зоной выборки.
  25. MONTHS_BETWEEN(большая дата, меньшая дата) = Дробное чило
    Если наоборот, то отрицательное число.
  26. MEDIAN (среднее по порядку) и AVG не приминают в параметре строку
  27. Все групповые (агрегирующие) функции принимают только NOT NULL значения.
  28. RANK( expression1, ... expression_n ) WITHIN GROUP ( ORDER BY expression1, ... expression_n )
    
    Ранк группы, если записей с одним ранком несколько, то им проставляется один номер.
  29. HAVING может использоваться только в SELECT после WHERE (можно даже без GROUP BY)
  30. * > ALL (<..>) - TRUE, если все строки подзапроса больше, или подзапрос ничего не! вернул
    * > SOME (<..>) - TRUE, если хотябы одна строка подзапроса больше, FALSE - подрапрос ничего не вернул
  31. Нельзя делать сложные (составные) столбцы в VIEW и Create table as select без алиасов (общие правила именования столбцов таблиц)
  32. Обычные synonim (не public) также распространяется на всю бд, но права даны только текущему пользователю.
    В случае public synonim права автоматически даны всем пользовалям.
  33. Перекомпиляция VIEW:
    ALTER <..> compile;
  34. ALTER TABLE T ENABLE NOVALIDATE CONSTRAINT <..>;
    Не проверять constraint у уже сущесвующих записей (будет проверяться только у новых)
  35. SET CONSTRAINT <..> DEFERRED;
    * Не проверяет constraint до первого commit;
    * После прохождения commit, constraint автоматом сменяется на immdiate - проверять все данные сразу.
  36. Создание constraint с INDEX
    CREATE TABLE T (
     <..>,
     constraint <..> UNIQUE (<...>)
      USING INDEX (CREATE INDEX <..> ON <..> (<..>) )
    )
    
    * Такой индекс можно создать только по UNIQUE и PK constraint
    * NOT NULL ограничение нельзя использовать в USING INDEX и CHECK (только в inline)
  37. Перманентно дропнуть таблицу без возможности восстановить из корзины.
    PURGE TABLE <..>;
    
  38. Восстановление таблицы на состояние в прошлом (из корзины).
    * SCN - Номер коммита. Можно получить используя пакет FLASHBACK.get_system_change_number
    FLASHBACK TABLE <..> TO SCN <..>
    
    * TIMESTAMP - на определенное время
    FLASHBACK TABLE <..> TO TIMESTAMP <..>
    
    * RESTORE POINT - точка восстановления ( CREATE RESTORE POINT <..> )
    FLASHBACK TABLE <..> TO RESTORE POINT <..>
    
    * BEFORE DROPS - восстановит таблицу, индексы, гранты, constraints ( все, кроме FK )
    FLASHBACK TABLE <..> TO BEFORE DROPS;
    
  39. * Получение данных на определенное время (нельзя использовать подзапросы)
    SELECT * FROM <..> 
      * as of timestamp('дата','формат'); --на точное время
      * as of timestamp systimestamp - intreval '0 00:01:30' DAY TO SEC; --полторы минуты назад
      * VERSION BETWEEN [TIMESTAMP 'TS1' AND 'TS2'] --между датами
                        [SCN '1' AND '2'] --между коммитами
    
    * Показ версии ( в историю попадают записи перед commit)
    SELECT t.*, version_operation, RAWTOHEX(version_xid)
    FROM T
    VERSIONS BETWEEN TIMESTAMP minvalue AND maxvalue;
    
  40. Включение FlashBack
    * DDL (может указана в настройках бд)
    ALTER SESSION SET RECYCLEBIN=ON;
    
    * DML (может быть настроено при создании таблицы)
    ALTER TABLE <..> ENABLE ROW MOVEMENT;
    
  41. EXTERNAL - Внешние метаданные
    * Можно делать select
    * Нельзя: index, constraint, update, delete
    * Хранится в папке на сервере
    * Создание (синтаксис схож с синтаксисом SQL Loader )
    CREATE TABLE <..> (<cols>)
    ORGANIZATION EXTERNAL
    ( ... LOCATION ('file.csv') );
    
  42. Советы по оптимизации составных индексов:
    * Самые часто используемые столбцы должны идти первыми
    ** Поиск по первым столбцам - range scan
    ** Поиск по другим - scip scan
    Поиск по части индекса, для каждого уникального значения префикса индекса.
  43. INTERSECT - убираем дубликаты строк.
    Пересечение 2ух одинаковых строк с 2умя другими даст одну.
  44. CUBE/ROLLUP по одному столбцу добавляет лишь 1 строку - общий итог.
  45. * Системные представления хранятся в схеме SYS
    * DICTIONARY - описание всех таблиц
    * USER_<..> таблицы не имеют OWNER столбца
  46. Иерархические запросы:
    * Сортировка по полю внутри уровня.
    ORDER BY sibling by <..>;
    
    * Полный путь до уровня
    SYS_COMMENT_BY_PATH(col, '/')
    
    * Вывод данных в зависимости от уровня
    CONNECT_BY_ROOT COL -- данные из верха иерархии
    CONNECT_BY_LEAF COL -- данные из самого низа (листка)
    CONNECT_BY_CYCLE COL -- данные, где начался цикл
    
    * WHERE идет и выполняется перед START WITH
  47. * Выдача прав с возможностью дальнейшей передачи (ADMIN OPTION)
    GRANT CREATE ANY TABLE TO <..> WITH ADMIN OPTION;
    
    * REVOKE права - отбирает не только сами права, но и возможность передачи (если были даны через ADMIN OPTION )
  48. UNION с любым другими SET операторами аналогичен DISTINCT
    SELECT 1 FROM DUAL
    UNION ALL
    SELECT 1 FROM DUAL
    UNION
    SELECT 2 FROM DUAL
    
    Запрос даст 2 строки, не смотря что первый оператор UNION ALL.

четверг, 19 июня 2014 г.

Bitrix: применяем стили визуального редактора правильно

Почти все, кто разрабатывает на bitrix, знает, что можно создавать стили для визуального редактора.
Но тут возникает проблема, если стили визуального редактора отличаются от стилей сайта, а контент вставляется в разные части страницы, то нужно как-то однозначно определить место вставки текста из редактора.

Для решения этой проблемы я решил обернуть весь текст из визуального редактора в div с определенным классом и все стили наследовать от него.
Т.е. в файле стилей нам можно будет прописать оформление для всех элементов наследников этого класса. Тогда оформление будет выглядеть одинаково как в самом визуальном редакторе, так и в любой части страницы, т.к. весь код будет обернут в этот div.
Остается только вставлять этот див автоматически в визуальный редактор.
Для этого в init.php добавляем обработчик события подключения визуального редактора и при его инициализации создаем div в который поместим весь контент.
<?php
//событие подключения визуального редактора
AddEventHandler("fileman", "OnIncludeHTMLEditorScript", array("MyHandlers", "OnIncludeHTMLEditorScript"));


class MyHandlers {

   public static function OnIncludeHTMLEditorScript()
   {
      ?>
      <script type="text/javascript">
      //получаем указатель на полотно визуального редактора
      BXHTMLEditor.prototype.SetView_ = BXHTMLEditor.prototype.SetView;
      BXHTMLEditor.prototype.SetView = function (sType) {
         var result = this.SetView_(sType);
         var html = undefined;
         if(BX.browser.IsIE()) {
            try {
               html = this.pEditorDocument.body;
            } catch (e) {
               //
            }         
         } else {
            try {
               html = this.pEditorWindow.document.body;
            } catch (e) {
              //
            }
         }
         if( sType == "html" && html ) {
            //обертываем в DIV, если его еще нет
            if( html.innerHTML.indexOf('<div class="content">') == -1 ) {
              html.innerHTML = '<div class="content">'+html.innerHTML+'</div>';
            }
         }
         return result;
      };
      </script>
      <?
   }
}
?>

понедельник, 28 апреля 2014 г.

Две заметки о Bitrix

1. Для создания сложных форм на bitrix я использую кастомный компонент в котором вытаскиваю все данные о инфоблоке с помощью такого запроса:
function getIblockProps($id) {
 global $DB;
 $sql = "SELECT b.id, b.code, b.name,
   -----
   p.id as pid, p.code as pcode, p.name as pname, p.SORT psort, 
    UPPER(CASE 
     WHEN p.USER_TYPE IS NOT NULL THEN p.USER_TYPE
     WHEN p.PROPERTY_TYPE = 'S' AND p.ROW_COUNT > 1 THEN 'T'
     ELSE p.PROPERTY_TYPE
    END) as ptype, 
    CASE WHEN p.MULTIPLE = 'Y' THEN 1 END as pmultiple, CASE WHEN p.MULTIPLE = 'Y' THEN p.MULTIPLE_CNT END pmultiple_cnt, 
   CASE WHEN p.LINK_IBLOCK_ID > 0 THEN p.LINK_IBLOCK_ID END as piblock, 
   CASE WHEN p.IS_REQUIRED = 'Y' THEN p.IS_REQUIRED END preq, p.HINT as phint,
   -----
   e.ID as eid, e.VALUE as evalue, e.DEF as edef, e.SORT as esort
  FROM b_iblock b , b_iblock_property p
  LEFT JOIN b_iblock_property_enum e
  ON(e.property_id = p.id)
  WHERE b.id = %u
  AND b.id = p.IBLOCK_ID AND p.ACTIVE = 'Y'
  ORDER BY p.sort,e.SORT";
 $rs = $DB->Query( sprintf( $sql, intval($id) ) );

 $rows = array();
 while ($row = $rs->Fetch()) {
  $rows[] = $row;
 }

 return $rows;
}

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

2. Особенность создания товарных предложений через код.
Создали мы товарное предложение через код:
$el = new CIBlockElement;  
$id = $el->Add($arFields);

Задали цену:
CPrice::SetBasePrice( $id,  $arFields['PRICE'],  "RUB", 1);

Заполнили остатки:
$arFields = Array(
  "PRODUCT_ID" => $id,
  "STORE_ID" => 1,
  "AMOUNT" => $v['Количество'],
 );
 
CCatalogStoreProduct::Add($arFields);

Вроде все. Но товар не покупается, хотя все атрибуты присутствуют.

Чтобы все заработало, нужно еще раз добавить (именно добавить, а не обновить) предложение, но другой функцией:
$arFields = array('ID'=>$id, 'PRICE_TYPE' => 'S', 'QUANTITY' => floatval($f['Количество']));
CCatalogProduct::Add($arFields);

воскресенье, 28 июля 2013 г.

SQLite: две особенности этой базы

Хочу рассказать про 2 отличия SQLite от других БД, решение которых придется долго искать, если вы только начинаете работать с ней.

1. Приведение к верхнему регистру UPPER юникод строк UTF8.
Необходимость в этом у меня появилась при регистронезависимом поиске по подстроке LIKE и как оказалось поумолчанию эта функций в SQLite нет и предлагается самим ее реализовать.
В интернете множество вариантов решения через настройку SQLite и доустановку дополнительных пакетов. Но мне такой способ не подходил, т.к. на шаред хостинге это не сделать.

К счастью SQLite позволяет делать собственные пользовательские функции, чем мы и воспользуемся.
Далее код на php для создания собственной функции UPPER - UPPER_UTF8.
createFunction('UPPER_UTF8', 'upper_ru', 1);
//array('SQLITE_DB', 'upper_ru') - если используете в составе класса 'SQLITE_DB'

?>
После этих нехитрых манупуляций в составе SQLite появится новая функция UPPER_UTF8 и с помощью ее можно будет делать регистронезависимые запросы:
SELECT 
  t.* 
FROM
  table t
WHERE
  UPPER_UTF8(t.col) LIKE UPPER_UTF8('%кАкойТо Запрос%')

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

Далее 2 примера, сначала неправильный:
--таблица
CREATE TABLE "cashes" (
    "id" INTEGER PRIMARY KEY  NOT NULL,
    "date" DATE NOT NULL,
    "uid" INT(10) NOT NULL DEFAULT ('1'),
    "visible" TINYINT(4) NOT NULL DEFAULT ('1')
);

--индекс
CREATE INDEX "XIF_CASHES_DUV" on cashes (date DESC, uid ASC, visible ASC);

--вызов плана
EXPLAIN QUERY PLAN SELECT
      c.id, c.uid, c.date
     FROM cashes c
     WHERE
      c.date BETWEEN '2013-04-01' AND '2013-06-01'
      AND c.uid = 1 AND c.visible = 1
     ORDER BY
      c.date;

--план
SEARCH TABLE cashes AS c USING INDEX XIF_CASHES_USR (uid=?) (~2 rows)
А дальше, как нужно было правильно создавать индекс. Поле даты - поле диапозона, должно было идти последним:
--индекс
CREATE INDEX "XIF_CASHES_DUV" on cashes (uid ASC, visible ASC, date DESC);

--план запроса
SEARCH TABLE cashes AS c USING INDEX XIF_CASHES_DUV (uid=? AND visible=? AND date>? AND date<?) (~42 rows)
Причем если бы мы искали точное соответствие по дате, то сработали бы оба индекса, но при поиске по диапазону только последний.

вторник, 25 декабря 2012 г.

Firefox: пишем расширение для браузера

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

Внедерение своего скрипта в тело страницы
//защищенная часть скрипта - оборачиваем в анонимную функцию, чтобы не было повторов имен переменных
(function() {
    var YT_global_doc = undefined;

    var YT_loader = new function(){};
    YT_loader.run = function(e) {
        //проверяем адрес сайта
	var unsafeWin = e.target.defaultView;
	var unsafeLoc = new XPCNativeWrapper(unsafeWin, 'location').location;
	var href = new XPCNativeWrapper(unsafeLoc, 'href').href;
	if (!href.match(/^http:\/\/www\.xxxx\.com\/watch(.*)?$/i) )
	      return;

        //обращаемся к dom сайта
	YT_global_doc = e.target.defaultView.document;

	if(YT_global_doc) {

          //подгружаем наш скрипт
	  var script = YT_global_doc.createElement( 'script' );
	  script.type = 'text/javascript';
	  script.src = 'chrome://xxx/content/yyy.js';
	  YT_global_doc.body.appendChild(script);

	}
    };

    var yt_load = function() {
        //событие загрузки вкладки с сайтом, выполняется каждый раз при загрузке страницы
        window.document.addEventListener("DOMContentLoaded", YT_loader.run, true);
    };
    //событие загрузки приватной части - выполняется один раз
    window.addEventListener("load", yt_load, false);

})();


Правильное создание новых узлов в DOM
Внутренними правилами firefox запрещено обращаться и работать с dom через innerHtml. Взамен этого необходимо пользоваться шаблонами. В своих аддонах я пользуюсь JQuery Templating.
Вот пример:
$("#pv_actions").prepend (
      $("<a>", {
	href: 	"#",
	target: "_blank",
	text:	"Загрузить оригинал",
	id:	"pv_down_link"
      })
      .css("font-weight", "bold")
      .bind("click", function (o) {
	//
      })
);


Взаимодействие с защищенной частью скрипта
Аддон состоит из 2 частей: защищенной и внедренной (небезопасной части). В безопасной части можно работать с апи браузера: сохранять файл, делать ajax запросы и т.д.
Взаимодействовать эти две изолированные части могут только по средствам событий.
Рассмотрим пример: узнать размер файла.
В незащищённой части создаем событие с нашими параметрами.
  //yt_getFileSizeEvent - название события
  var element = document.createElement("yt_getFileSizeEvent");
  element.setAttribute("attribute_url", "адрес до файла" );
  element.setAttribute("attribute_id",  "индекс файла" );
  document.documentElement.appendChild(element);
  var evt = document.createEvent("Events");
  evt.initEvent("yt_getFileSizeEvent", true, false);
  element.dispatchEvent(evt);
В защищенной части ловим событие:
document.addEventListener("yt_getFileSizeEvent", function(e) { YT_secureEvent.getFileSize(e); }, false, true);
После этого обрабатываем и повторяем все в обратном порядке, чтобы передать данные в незащищённую часть скрипта.

суббота, 1 декабря 2012 г.

Советы по оптимизации SQL запросов

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

Другие статьи по оптимизации SQL

1. Ни каких подзапросов, только JOIN
Как я уже писал ранее, если выборка 1 к 1 или надо что-то просуммировать, то ни каких подзапросов, только join.
Стоит заметить, что в большинстве случаев оптимизатор сможет развернуть подзапрос в join, но это может случиться не всегда.

2. Выбор IN или EXISTS ?
На самом деле это сложный выбор и правильное решение можно получить только опытным путем.
Я дам только несколько советов:
* Если в основной выборке много строк, а в подзапросе мало, то ваш выбор IN. Т.к. в этом случае запрос в in выполнится один раз и сразу ограничит большую основную таблицу.
* Если в подзапросе сложный запрос, а в основной выборке относительно мало строк, то ваш выбор EXISTS. В этом случае сложный запрос выполнится не так часто.
* Если и там и там сложно, то это повод изменить логику на джойны.

3. Не забывайте про индексы
Совет для совсем новичков: вешайте индексы на столбцы по которым джойните таблицы.

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

5. По возможности не используйте WITH в oracle.
Значительно облегчает жизнь, если запрос в with необходимо использовать несколько раз ( с хинтом materialize ) в основной выборке или если число строк в подзапросе не значительно.
Во всех других случаях необходимо использовать прямые подзапросы в from или взаранее подготовленную таблицу с нужными индексами и данными из WITH.
Причина плохой работы WITH в том, что при его джойне не используются ни какие индексы и если данных в нем много, то все встанет. Вторая причина в том, что оптимизатору сложно определить сколько данных нам вернет with и оптимизатор не может построить правильный план запроса.
В большинстве случаев WITH без +materialize все равно будет развернут в основной запрос.


6. Не делайте километровых запросов
Часто в web обратная проблема - это много мелких запросов в цикле и их советуют объединить в один большой. Но тут есть свои ограничения, если у вас запрос множество раз обернутый в from, то внутреннюю(ие) части надо вынести в отдельную выборку, заполнить временную таблицу, навесить индексы, а потом использовать ее в основной выборке. Скорость работы будет значительно выше (в первую очередь из-за сложности построения оптимального плана на большом числе сочетаний таблиц)

7. Используйте KEEP взамен корреляционных подзапросов.
В ORACLE есть очень полезные аналитические функции, которые упростят ваши запросы. Один из них - это KEEP.
KEEP позволит сделать вам сортировку или группировку основной выборки без дополнительно запроса.
Пример: отобрать контрагента для номенклатуры, который раньше остальных был к ней подвязан. У одной номенклатуры может быть несколько поставщиков.
SELECT n.ID, MIN(c.ID) KEEP (DENSE_RANK FIRST ORDER BY c.date ASC) as cnt_id
FROM nmcl n, cnt c
WHERE n.cnt_id = c.id
GROUP BY n.ID
При обычном бы подходе пришлось бы делать корреляционный подзапрос для каждой номенклатуры с выбором минимальной даты.
Но не злоупотребляйте большим числом аналитических функций, особенно если они имеют разные сортировки. Каждая разная сортировка - это новое сканирование окна.

8. Гуляние по выборке вверх-вниз
Менее популярная функция, но не менее полезная. Позволяет смещать текущую строку выборки на N элементов вверх или вниз. Бывает полезно, если необходимо сравнить показатели рядом стоящих строк.
Следующий пример отбирает продажи департаментов отсортированных по дате. К основной выборке добавляются столбцы со следующим и предыдущим значением выручки. Второй параметр - это на сколько строк сместиться, третьи - параметр по-умолчанию, если данные соседа не нашлись.
SELECT deptno, empno, sal,
LEAD(sal, 1, 0) OVER (PARTITION BY dept ORDER BY date) NEXT_LOWER_SAL,
LAG(sal, 1, 0) OVER (PARTITION BY dept ORDER BY date) PREV_HIGHER_SAL
FROM emp;
ORDER BY deptno, date DESC;
При обычном подходе бы пришлось это делать через логику приложения.

9. Direct Path Read
Установка этой настройки (настройкой или параллельным запросом) - чтение данных напрямую в PGA, минуя буферный кэш. Что укоряет последующие этапы запроса, т.к. не используется UNDO и защелки совместного доступа.

10. Direct IO
Использование прямой записи/чтения с диска без использования буфера файловой системы (файловая система конкретно для СУБД).
* В случае чтения преимущество в использовании буферного кэша БД, замен кэша ФС (кэш бд лучше заточен на работу с sql)
* В случае записи, прямая запись гарантирует, что данные не потеряются в буфере ФС в случае выключения электричества (для redolog всегда использует fsync, в не зависимости от типа ФС)

11. Оптимизация параллельных запросов
12. Оценка стоимости запроса и построение правильного плана
13. Оптимизация работы секционированных таблиц
14. Индексный поиск
15. Оптимизация запросов вставки
16. Ускорение pl/sql циклов
17. И другое...

четверг, 22 ноября 2012 г.

ORACLE: логирование всех DDL операций.

Вот такой небольшой триггер позволит сохранить все операции DDL, происходящие во всех схемах БД. DDL (Data Definition Language) - описание структур объектов базы.
Триггер выполняется после DDL операции и сохраняет: тип объекта (ora_dict_obj_type), схему (ora_dict_obj_owner), имя объекта (ora_dict_obj_name), имя пользователя , дата операции, тип DDL операции (ora_sysevent), имя компьютера и CLOB с текстом DDL операции (ora_sql_txt).
create or replace TRIGGER bi_sa_psk.trg_ddl_trig_hist
 AFTER DDL
 ON DATABASE
declare
  PRAGMA AUTONOMOUS_TRANSACTION;

  v_ddl CLOB := EMPTY_CLOB;
  li ora_name_list_t;
  l_n number;
BEGIN
  /* sys создает системные временные таблицы для sql запросов */
  IF ora_dict_obj_owner = 'SYS' THEN
    return;
  END IF;

  /* Получим текст DDL */
  l_n := ora_sql_txt(li);
  for i in 1 .. l_n loop
    v_ddl := v_ddl || TO_CLOB(TO_CHAR(li(i)));
  end loop;

  /* запишем историю */
  INSERT INTO bi_sa_psk.ddl_hist(object_type, owner, object_name, USER_NAME, DDL_DATE, DDL_TYPE, COMP_NAME, DDL_TXT, stack)
  VALUES(UPPER(ora_dict_obj_type), UPPER(ora_dict_obj_owner), UPPER(ora_dict_obj_name), ora_login_user, SYSDATE, ora_sysevent, SYS_CONTEXT ('USERENV', 'OS_USER'), v_ddl, dbms_utility.format_call_stack);
  commit;

  /* любые ошибки игнорируем, что бы не завалить БД целиком */
  EXCEPTION WHEN OTHERS THEN NULL;
END trg_ddl_trig_hist;
/
Такая штука будет очень полезна, чтобы вернуть утерянные изменения или отыскать виновного в баге :) .

воскресенье, 9 сентября 2012 г.

Yandex Map: Открытие балуна метки, объединенной в кластер

Все, кто работает с Yandex картами, знают что открыть балун (ballon) на точке карты (Placemark) с внешней ссылки простое дело.
Но это не так просто сделать для точек, объединенных в кластер (Cluster). Причина этого в том, что точки физически не существует на карте, в целях оптимизации на карте есть только кластер.

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

Я расскажу, как реализовать 3ий вариант, как самый простой.