Загружаем большие объемы данных в oracle

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

Например , вы хотите заполнить биллинговую БД десятью миллионами клиентов, которые тянут за собой другие десятки миллионов сопутствующих записей в разных таблицах схемы (речь в данном посте идет именно о реляционных субд).

Каждая реляционная субд имеет свои механизмы дампа, заливки, импорта , экспорта... Даже простецкий sqlite имеет свой  .dump.

Я бы хотел поделиться некоторыми аспектами создания больших объемов тестовых данных в субд Oracle.

Существует несколько вариантов:

Самый неудачный вариант - с наскока написать скрипт, который бы генерировал данные с помощью обычного DML. Подобное решение будет работать долго и потреблять слишком много ресурсов субд, связанных с ведением redo-логов, распуханием сегмента отката, фиксацией изменений (commit).

Другой вариант - использовать штатные оракловые утилиты бекапа и восстановления : imp , exp , которые очень шустро работают. Но этот вариант применим в ситуации, когда у вас уже имеется эталонная схема с нужным количеством данных - вы просто экспортируете (в бинарный файл) из нее все или часть данных и импортируете в нужную схему из полученного бинарного дампа. Например, таким образом, можно слить данные с боевой БД заказчика, разумеется, если он дает на это добро. К тому же использовать этот метод рекомендуется для работы с БД до 50 - 60 GB.

Ну и наиболее подходящий вариант - использование SQL*Loader.
Метод относительно быстр , гибок в настройке хоть и имеет свои особенности. Загрузка осуществляется оракловой утилитой sqlldr.
Ей на вход необходимо передать обязательно: управляющий файл и файл с данными, и необязательно  - файл пераметров.

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

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

Файл с параметрами - текстовый файл , в котором указываются параметры командной строки. Например sqlldr PARFILE=parameters.par 

Что же делает imp , sqlldr быстрыми? В первую очередь то, что они умеют использовать такую возможность Oracle, как метод "прямой вставки".

Прямая вставка - это почти тот же insert, который быстрее обычного за счет того , что при его использовании не тратится время на коммиты, redo-логи, большинство ограничений (кроме unique, primary key и not null) и insert-триггеры.
Чтобы sqlldr использовал метод прямой вставки, ему необходимо передать в командной строке или файле параметров опцию DIRECT=Y.
Кроме того, прямую вставку можно еще и распараллелить.
К слову, такой метод вставки можно использовать и самостоятельно.

Вот пример параллельного (в  2 процесса)  и нежурналируемого копирования данных из одной таблицы в другую.

ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+parallel(new_users,2)*/ INTO users NOLOGGING
SELECT * FROM old_users

Наибольший выигрыш от распараллеливания  загрузки достигается на тех серверах, где более одного CPU.

Ну и напоследок несколько советов о том, как сделать процесс загрузки более оптимальным:

1. подготовьте место да диске, где будут лежать dbf-ы новой базы, достаточное для будущего объема данных (посмотрите сколько занимают dbf-ы старой =)
2. отключите индексы в таблицах , которые собираетесь заполнять
3. используйте прямую и по возможности параллельную вставку
4. отключите архиватор, если включен (напарывался на ситуацию, когда архиватор отжирал место почти равное тому, что занимала новая база - это совершенно ненужное при генерации тестовых данных архивирование!):

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;


Если же архиватор все таки не был отключен и отожрал место на диске архивными dbf-ами, то их можно легко удалить.
Для этого в папке с архивными dbf-ами удалить все ненужные архивы и после этого с помощью rman избавиться от соответствующих записей в БД:

rman target sys@dbsid

crosscheck archivelog all;

delete noprompt expired archivelog all;

Хорошую подборка проверенных советов по оптимизации именно SQL*Loader можно найти здесь

На полноту охвата темы не претендую, но , надеюсь, у того кто с описанными вкратце механизмами не знаком , появится вектор, куда копать в случае необходимости :)

Практичный WWW::Mechanize

Так сложилось, что мне частенько приходится пользоваться различными виртуальными хостингами.
С недавнего времени среди тех, которыми я часто пользуюсь появился такой хостер, который разрешает подключаться к серверу по SSH только с одного IP.
При этом , конечно же, позволяет указывать разрешенный IP в хостинг-панели.
В целом, штука конечно-же, секьюрная , но немного неудобная.
Теперь мы все стали мобильные, наши IP-ы часто меняются - дома один, в дороге или кафе - другой,  в офисе - третий.
Один раз залезешь - переключишь, другой, а на третий уже автоматизируешь.
Так поступил и я... В голове сразу мелькнули мысли от трех вариантах - Selenium, Jmeter и гипотетический perl-скрипт с использованием WWW::Mechanize.

По ряду причин решил использовать второй третий вариант...

Для этого нужно:

1. perl  c установленным WWW::Mechanize, а лучше и Test::WWW::Mechanize
2. Firefox с включенным плагином MozRepl ( ТОЛЬКО ЕСЛИ ЗАХОТИТЕ СНИМАТЬ СКРИНШОТЫ!)
3. Пара минут времени

#!/usr/bin/perl -w use utf8;
 use Test::More "no_plan"; 
 use Test::WWW::Mechanize; 
 use constant URL => 'нужный урл'; 
 use constant LOGIN =>; 'логин к админ панели'; 
 use constant PASSWORD =>; 'пароль к админ панели'; 

 my $m = Test::WWW::Mechanize->new(autolint=>0); 
 $m->get_ok( URL , 'Open login page'); 
 $m->content_contains( 'Контрольная панель' , 'Check we are on right page'); 
 $m->submit_form_ok({ 
    form_number =>; 1, 
    fields => { 
      login => LOGIN, 
      password => PASSWORD, 
    }, 
 } , 'Submit login form' ); 
 $m->follow_link_ok( { 
        text_regex => qr/Настройки SSH/i 
     } , 'Follow ssh settings link'); 
 $m->content_contains( 'Настройки SSH' , "Check we are on right page"); 
 $m-$gt;follow_link_ok( {id =>; 'user-ip' }, "Allow current ip"); 
 my $link =$m->find_link( id => 'user-ip' ); ok($link, 'Get current ip from page'); 
 $m->submit_form_ok({ form_number => 1, fields => { ip => $link->text, }, } , 'Submit ip changing form' );


В скрипте используется Test::WWW::Mechanize - обертка над WWW::Mechanize  , которая используется в написании автотестов, что делает этот скрипт по сути автотестом с наглядным логированием в консоль:

$ ./ssh_switcher 
ok 1 - Open login page 
ok 2 - Check we are on right page 
ok 3 - Submit login form 
ok 4 - Follow ssh settings link 
ok 5 - Check we are on right page 
ok 6 - Allow current ip 

ok 7 - Get current ip from page
ok 8 - Submit ip changing form
1..8

Ну и этот "тест" потестить тоже надо бы.. Убеждаемся, что до запуска ssh-соединение не устанавливаетса, а после запуска - проблем нет.

Таким образом, скрипт реально экономит мне время и нервы, позволяя одним кликом разрешить текущий ip-с которым я вышел в сеть - не надо открывать браузер, панель, помнить и вводить логин , пароль (очень хитрый и длинный пароль)...

Разумеется, это  подходит только для данного конкретного хостера и его алгоритма смены разрешенного ip ) И, конечно же, хостер может изменить названия переменных, ссылок, вообще поменять логику - это не проблема, скорректировать скрипт дело пары минут :)

Не а ежели хостер навесит капчу, то будет очень интересно решить эту задачу, тем более, что кое-какие наработки где-то в дебрях харда валялись )

p.s. в целом WWW::Mechanize очень даже применим для автоматизации сценариев , а его обертка Test::WWW::Mechanize - даже для создания функциональных автотестов.