20.03.2012 11:46
В общем не знаю может кому поможет, а может кто мне еще подскажет чего...
База у нас перевалила за 200 гигов и приходиться вводить новый сервер для построения отчетов...
опишу конфигурацию сервера: HP (dl 180) 2 проца по 4 ядра ксеон 5520 по 2.27, 6 гигов оперативки ддр3 в 3м канале 3 рейда, 1 sas 146 10k raid 10 (диск C) 2 sas 146 15k raid 10 (диск D) 3 ssd 128 ocz vertex 3 raid 0 (диск E)
Windows Server 2008 x86, Oracle 10g

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

ну вот батник на все операции


***** RELOADDB_.CMD

@echo off

:: Удалим файл флаг предидущей заливки
::

del C:\ReloadDB\reload.flg /q /f

:: Создадим файл флаг начала
::

echo Start in %Date% %Time% > C:\ReloadDB\reload.flg


:: Подключаемся к 192.168.1.1 и копируем дамп
::

NET USE N: \\192.168.1.1\Dumps /user:sm\admin "adm"
COPY N:\export_base.dmp D:\ReloadDB\export.dmp /y /z /v

:: Стопим сервисы базы и сервера приложений супермага
::

"%windir%\system32\net.exe" stop OracleServiceREPORT
"%windir%\system32\net.exe" stop "Supermag Server"

:: Удаляем старую базу и конфиги и заменяем их на пустые
::

del E:\oracle\oradata\REPORT\*.* /Q /F
copy D:\Clear_DB\REPORT\*.* E:\oracle\oradata\REPORT\ /v /y
rmdir /s /q C:\oracle\product\10.2.0\admin\REPORT
mkdir C:\oracle\product\10.2.0\admin\REPORT
robocopy D:\Clear_DBA\REPORT C:\oracle\product\10.2.0\admin\REPORT /e

:: Стартуем сервис базы
::

"%windir%\system32\net.exe" start OracleServiceREPORT

:: Импортируем базу и убиваем дамп
::

imp sys/qqq@report full=y file=D:\ReloadDB\export.dmp log=C:\ReloadDB\logs\import_%date%.log
del D:\ReloadDB\export.dmp /Q /F

:: Грохаем таблички с ключиком от старой базы и заливаем правильные
:: с ключиком для новой
::

echo ** Work DROP_TABLES.sql >C:\ReloadDB\logs\SQL_SCRIPT.log
SQLPLUS supermag/qqq@report @C:\ReloadDB\DROP_TABLES.sql >>C:\ReloadDB\logs\SQL_SCRIPT.log
IMP.EXE 'sys/qqq@report as sysdba' file=C:\ReloadDB\Lic\KEY.dmp ignore=y tables=(SSSYSINFO,SMCLIENTAPPS,SMCLIENTFUNCTIONS) fromuser=SUPERMAG touser=SUPERMAG log=C:\ReloadDB\logs\KEY_UPDATE.log


:: Даём гранты supermag`у
::

echo ** Work GRANTS.sql >>C:\ReloadDB\logs\SQL_SCRIPT.log
sqlplus.exe sys/qqq@report @C:\ReloadDB\GRANTS.sql >>C:\ReloadDB\logs\SQL_SCRIPT.LOG

:: Удаляем ненужные линки и таблички
::

echo ** Work DROPLINK.SQL >>C:\ReloadDB\logs\SQL_SCRIPT.log
sqlplus.exe sys/qqq@report @C:\ReloadDB\DROPLINK.SQL >>C:\ReloadDB\logs\SQL_SCRIPT.LOG

:: Перекомпиляция процедур
::

cd C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\
sqlplus.exe sys/qqq@report @C:\ReloadDB\utlrp_.sql >C:\ReloadDB\logs\RDBMS.LOG
cd C:\ReloadDB\

:: Добавляем недостающие CONSTRAINT
::

echo ** Work CONSTRAINT.sql >>C:\ReloadDB\logs\SQL_SCRIPT.log
SQLPLUS supermag/qqq@report @C:\ReloadDB\CONSTRAINT.sql >>C:\ReloadDB\logs\SQL_SCRIPT.log


:: "Генератор БД", с переносом индексов в INDX
::

cd C:\ReloadDB\InitScripts\INSTANCE\
SQLPLUS supermag/qqq@report @C:\ReloadDB\InitScripts\INSTANCE\_SQL_SCRIPT_INIT.SQL >C:\ReloadDB\logs\DBINIT.log
SQLPLUS sys/qqq@report @C:\ReloadDB\InitScripts\INSTANCE\_SQL_SCRIPT_INDX.SQL >>C:\ReloadDB\logs\DBINIT.log
SQLPLUS supermag/qqq@report @C:\ReloadDB\InitScripts\INSTANCE\_SQL_SCRIPT_INS.SQL >>C:\ReloadDB\logs\DBINIT.log
cd C:\ReloadDB\

:: прогоняем сервис пак 4
::

cd C:\ReloadDB\InitScripts\sp\
SQLPLUS supermag/qqq@report @C:\ReloadDB\service_p.sql >C:\ReloadDB\logs\SP_INIT.log
cd C:\ReloadDB\

:: Стартуем сервис сервера приложений супермага
::

"%windir%\system32\net.exe" start "Supermag Server"


:: Отключаемся от 192.168.1.1
::

NET USE N: /DELETE /YES


:: Запишем файл флаг окончания
::

echo End in %Date% %Time% >> C:\ReloadDB\reload.flg



:: Автоматический расчет товародвижения для СМ2000.
:: td paswrd ! /stat 5

:: cd C:\SM2000\Bin\
:: C:\SM2000\Bin\td.exe qqq ! /stat 5
:: cd C:\ReloadDB\

:: debug
::

pause


вот на извлечение ключа


***** LIC_EXTRACT.CMD

@echo off
set NLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251
EXP.EXE 'supermag/qqq@report' file=C:\ReloadDB\Lic\key.dmp tables=(SUPERMAG.SSSYSINFO,SUPERMAG.SMCLIENTAPPS,SUPERMAG.SMCLIENTFUNCTIONS) consistent=y log=C:\ReloadDB\Lic\KEY_exp.log


а тут все файлы ReloadDB.rar

Добавлено через 3 минуты 2 секунды
а забыл написать СМ+ версии 1.029 сп6
20.03.2012 12:18
Добавил репутации, спасибо за интересный пример.
ReloadDB.rar положил на временное хранение... Пропадет...
Есть ряд вопросов (прошу воспринимать, не как наезд, а как повод пересмотреть еще раз подход)
1) 200Гб база не на х64... Немного странно, почему? Денег на 16Гб не дают, а на SSD дали? Можно получить прирост быстродействия весьма неслабый, допускаю, что второго сервера может и не понадобиться
2) нет скрипта на экспорт, со штатными настройками на таком объеме - потеря для сервера (никому нельзя работать) где-то 6 часов?
3) не очень понятно, зачем скрипты на генерацию БД, они разных версий?
4) почему именно дамп? почему, например, не просто файлами бабахнуть?

как бы я поступил - однозначно делал бы по другому, т.е. сначала бы соотнес параметры железа и размеры БД. Чтобы хоть какую-то арифметику привязать - возьми размер самого большого сегмента и умножь надвое. Это будет объем твоей оперативки. Ни разу не точная формула, но хоть что-то. потом, тут на форуме есть дока по дублированию БД. На средненькой Solaris-sparc база в 60Гб дублируется минут за 20. Дамп - это уже в каком-то самом крайнем и непонятном мне случае. Если не хочешь ковыряться и учить RMAN - прибивай БД, убедись, что остановилась и перебрось файлики, базу запусти, прибей лицензию, как уже умеешь... С дампом столько граблей можно собрать, да и собирается он долго.
20.03.2012 15:22
Цитата:
OlegON Добавил репутации, спасибо за интересный пример.
ReloadDB.rar положил на временное хранение... Пропадет...
Есть ряд вопросов (прошу воспринимать, не как наезд, а как повод пересмотреть еще раз подход)
1) 200Гб база не на х64... Немного странно, почему? Денег на 16Гб не дают, а на SSD дали? Можно получить прирост быстродействия весьма неслабый, допускаю, что второго сервера может и не понадобиться
2) нет скрипта на экспорт, со штатными настройками на таком объеме - потеря для сервера (никому нельзя работать) где-то 6 часов?
3) не очень понятно, зачем скрипты на генерацию БД, они разных версий?
4) почему именно дамп? почему, например, не просто файлами бабахнуть?

как бы я поступил - однозначно делал бы по другому, т.е. сначала бы соотнес параметры железа и размеры БД. Чтобы хоть какую-то арифметику привязать - возьми размер самого большого сегмента и умножь надвое. Это будет объем твоей оперативки. Ни разу не точная формула, но хоть что-то. потом, тут на форуме есть дока по дублированию БД. На средненькой Solaris-sparc база в 60Гб дублируется минут за 20. Дамп - это уже в каком-то самом крайнем и непонятном мне случае. Если не хочешь ковыряться и учить RMAN - прибивай БД, убедись, что остановилась и перебрось файлики, базу запусти, прибей лицензию, как уже умеешь... С дампом столько граблей можно собрать, да и собирается он долго.
отвечу по порядку...

1) это конфиг сервера отчетов был (т.е. на котором поднимается все) рабочая же конфигурация с рабочей базой несколько иная - там 24 озу, 2 проца по 4 ядра ксеон 5620 по 2.4 , 5 зеркалок sas 146 15k (помоему),
Win2008Server x64, Oracle 10g x64.
на сервере отчетов x86 Потому что на тот момент ненашлось других дисков... да и сервер брали лишь поть будут ли быстрее отчеты крутиться или нет, в будушем планирую его проапгрейдить и поменять ос.

2) была идея выгружать только supermag но там с пользователями тогда засада, все делается в выходные - а это не рабочие дни ... (10 часов копирование и заливка у меня идет)

3) ну просто я всегда после перезаливки базы привык прогонять генератор бд и сервис пак ( порекомендовал мне это Марный Сергей из СП) хуже то не станет...

4) дамп весит меньше... (так база весит 200 а в дампе 58)

ну в принципе меня устраивает как оно щас работает....
Часовой пояс GMT +3, время: 10:39.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.