Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Помогите советом, плиз!!!

Очень требуется консультация.
Ситуация следующая.

У нас в компании используется СУБД ORACLE, которая сконфигурирована на сырых дисках. Вся система работает на серверах с HP-UX. Используется VxFS. По ошибке системного администратора один из сырых дисков, который использовался под индексы для ORACLE, был расширен при помощи графической оболочки Veritas Enterprice Administrator. При этом создался дополнительный subdisk, который оказался в конце уже созданных subdisks. Первоначально размер сабдиска составлял 64 Гигабайта, который мапировался к плексу и далее создавался volume, но после расширения размер volume стал равен 68 Гбайт, при этом ORACLE продолжает видеть размер расширенного диска, как 64 Гбайта.

Таким образом получилась конструкция состоящая из двух сабдисков, примапированных к плексу, на котором был создан volume – сырой диск, используемый ORACLE, для индексов. Можно ли создать заново subdisk размером 64 Гбайта, и далее plex и volume, на который при помощи команды dd можно было бы скопировать содержимое расширенного (68Гбайт) сырого диска на новый (64Гбайт) сырой диск? Как вообще на это посмотрит ORACLE? Что при этом может произойти?

Как еще можно вернуться к прежнему размеру диска в 64Гбайта?

Почему 64? Потому что именно такого размера создается volume на другом сервере, на который производится так называемая репликация, суть которой заключается в mirroring’е плексов (синхронизации) с дальнейшем переносом на другой сервер (сервер разработчиков), где на основе синхронизированных плексов создаются volumes.

Если есть какие-то мысли, очень прошу помочь…

Использование команды dd?
9 май 06, 06:17    [2643959]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6876
Учитывая, что "ORACLE продолжает видеть размер расширенного диска, как 64 Гбайта", думаю, можно спокойно использовать dd. Очевидно, что датафайл не выходит за пределы 64 Гб, т.ч. физически ничего и никогда не писалось на добавленные в конец 4Гб.

P.S. Не силён в тонкостях VxFS, могу ошибаться. Может, оно физически не в конец, а в середину добавляет, перемешивая добавленный кусок с имеющимися :)

Отступать некуда
9 май 06, 12:14    [2644165]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Scott Tiger
Учитывая, что "ORACLE продолжает видеть размер расширенного диска, как 64 Гбайта", думаю, можно спокойно использовать dd. Очевидно, что датафайл не выходит за пределы 64 Гб, т.ч. физически ничего и никогда не писалось на добавленные в конец 4Гб.

P.S. Не силён в тонкостях VxFS, могу ошибаться. Может, оно физически не в конец, а в середину добавляет, перемешивая добавленный кусок с имеющимися :)

Отступать некуда


Главное, чтобы веритас не создал вам там файловую систему?

А так - в чем проблема то? В Веритасе урежте диск обратно (по моему, это можно сделать руками, если там нет файловой системы - если она есть, то он сделает это из гуи влегкую), ну или живите как живете. dd просто будет падать в самом конце, хотя вам никто не мешает указать там число блоков, чтобы не падала.

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

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

PPS. Веритас вообще удивительно живучая система - сколько я не извращался, ни разу ничего сломать не удалось.
9 май 06, 22:28    [2645000]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Еще мысля - а может, раз уж добавили на первой системе 4 гига, просто добавить 4 гига на копии, увеличить на эти 4 гига таблеспейс, и не мучаться вообще? То есть _уж если получилось так - дык используйте то что получилось_?

ИМХО, самый правильный путь на рабочей системе.
9 май 06, 22:30    [2645003]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Все равно спасибо, надо попробовать переписать командой dd и подставить ораклу. Предварительно сделав на случай непредвиденных обстоятельств бекап.
9 май 06, 23:09    [2645105]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Дело в том, что на там, где располагается зеркало диска (плекса) уже нет места
9 май 06, 23:11    [2645108]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Спасибо за советы.
Дело в том, что при расширении volume, к плексу, добавился еще один сабдиск, который создался автоматически (видимо многое делается автоматически через VEA, т.к. она использует команды vxassist). И вот этот второй появившийся сабдиск в 4 Гб оказался в конце набора других сабдисков. Создав подобную конструкцию на тестовом диске, т.е. volume сабдиск которого находился в самом начале, затем следующий volume, сабдиcк которого начинался после окончания сабдиска первого (был смещен на disk offset). После я сделал resize первого диска, при этом так же создался принадлежавший расширенному volume сабдиск, который встал уже в конце второго сабдиска. Это означает, что его нельзя например обьединить (Join) с первым сабдиском. Тогда я попытался сделать диссоциацию сабдиска в 4 Гб, но вылетела ошибка, в которой писалось, что если я сделаю так, то плекс обнулиться (что это означает я не знаю), но если я все же хочу, то должен буду форсировать, т.е. написать так: vxsd -g rootdg -o force dis subdisk4GB.
Затем так vxedit -g rootdg -rm subdisk4GB. вся конструкция действительно поломалась. Плекс стал каким-то странным, а размер первого volume (которому пренадлежал создавшийся сабдиск) уже нельзя было изменять.
После этого я начал экспериментировать с dd.
Весь вопрос для меня еще в том, что я не понимаю, как ORACLE использует сырой диск, когда не полностью его заполнил. Как он заполняет пространство внутри сырого диска?


Alex Roudnev
Scott Tiger
Учитывая, что "ORACLE продолжает видеть размер расширенного диска, как 64 Гбайта", думаю, можно спокойно использовать dd. Очевидно, что датафайл не выходит за пределы 64 Гб, т.ч. физически ничего и никогда не писалось на добавленные в конец 4Гб.

P.S. Не силён в тонкостях VxFS, могу ошибаться. Может, оно физически не в конец, а в середину добавляет, перемешивая добавленный кусок с имеющимися :)

Отступать некуда


Главное, чтобы веритас не создал вам там файловую систему?

А так - в чем проблема то? В Веритасе урежте диск обратно (по моему, это можно сделать руками, если там нет файловой системы - если она есть, то он сделает это из гуи влегкую), ну или живите как живете. dd просто будет падать в самом конце, хотя вам никто не мешает указать там число блоков, чтобы не падала.

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

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

PPS. Веритас вообще удивительно живучая система - сколько я не извращался, ни разу ничего сломать не удалось.
9 май 06, 23:40    [2645204]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
А вы не путаете термины? Я что то сомневаюсь, что у вас raw на сырых дисках - наверное, оно у вас на томах веритаса?

А тома достаточно легко ресайзить, в конце концов. В крайнем случае - сделайте еще один, перепишите туда 64 гига, убейте старый и переименуйте новый.

(команда называется vmsa - гуя к веритасу).

В общем, советы:
- работайте внутри вольюмов. Что то мне говорит, что вы на сырых дисках и не работаете на самом деле. Вы ресайзили диск на SAN системе и работаете на (/dev/vx/rdmp/* )? Если нет, то это уже вольюмы будут. А если на сырых дисках, то при чем тут веритас (кроме dmp модуля)?

- не удаляйте ничего forced. Если vmsa что то отказывается - то лучше это не делать. Исключение у меня было - удаление ненужных половин зеркала, но при этом есть грабли - проследите чтобы зеркало было синхронизовано полностью ДО удаления, а иначе после удаления у вас зеркало останется в недоделанном статусе до перевызова системы (и например, нельзя будет сделать relayout).

- вы можете сделать resize вольюму в любую сторону, при этом, если там нет
vxFS, то данные должны ресайзить вы сами. В вашем случае у вас и так пустуют 4 гига, вот и скажите веритасу _уменьшить размер на эти 4 гига_. (но тут надо быть Очень осторожным, так как гиги бывают очень разными).

- VX лучше вас знает, как данные по дискам размещать. Очень неймется - сделайте evacuate на новый диск, он будет немного пооптимальнее разпилен (потом можете сделать назад). Ну или сделайте reallocate, тоже на новый диск.
Благо все это идет on-line.

- и еще раз - 4 гига на фоне 64-х роли обычно не играют, я бы плюнул и ничего не трогал вообще. Померял бы реальное число рекордов, которые переписывает та dd, что падает по нехватке места в of=, и поставил бы там явно count= .

- Все это еще одно подтверждение старой истины, что НЕ НУЖНО использовать raw! Копеечная экономия скорости не оправдывает сильно не копеечного геммороя.
10 май 06, 03:45    [2645666]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Посмотрел доки.

Написано
- vxassist shrinkto VOLUME_NAME new_size (blocks)
- не уменьшайте размер ниже, чем размер имеющейся там у вас файловой системы или базы данных
- для VxFS, можно использовать vxresize
- для UFS, можно использовать vxresize
- можно использовать vxvol.

Что будет если убить дополнительный плекс - надо проверить (экспериментально), но если вы можете ТОЧНО указать требуемый размер в блоках - то дорога ваша к vxassist.

pS. А при чем тут Оракл?
10 май 06, 03:51    [2645667]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Я поступил так, что просто научился пользоваться оракловским менеджером восстановления (RMAN'ом). Оказывается, там все не так уж и сложно. Разобрался по одной оракловской книге, как им правильно пользоваться, а фактически он делает все сам. У нас конечно делается бекап, но он делается при помощи LEGATO, и им никто не пользовался на практике уже полгода со времени увольнения предыдущего системного администратора.

До общения с RMAN'ом я проводил такие эксперименты.

Во-первых, как я писал, при расширении volume, к плексу, добавился еще один сабдиск, который создался автоматически (видимо многое делается автоматически через VEA, т.к. она использует команды vxassist). И вот этот второй появившийся сабдиск в 4 Гб оказался в конце набора других сабдисков. Создав подобную конструкцию на тестовом диске, т.е. volume, сабдиск которого находился в самом начале, затем следующий volume, сабдиcк которого начинался после окончания сабдиска первого (был смещен на disk offset). После я сделал resize первого диска, при этом так же создался принадлежавший расширенному volume сабдиск, который встал уже в конце второго сабдиска. Это означает, что его нельзя например обьединить (Join subdisk) с первым сабдиском. Тогда я попытался сделать так называемую диссоциацию сабдиска в 4 Гб, но вылетела ошибка, в которой писалось, что если я сделаю так, то плекс обнулится (что это означает я не знаю), но если я все же хочу, то должен форсировать, т.е. написать так: vxsd -g rootdg -o force dis subdisk4GB.

Затем так vxedit -g rootdg -rm subdisk4GB. Я и форсировал, при этом вся конструкция действительно поломалась. Плекс стал каким-то странным, а размер первого volume (которому принадлежал создавшийся сабдиск) уже нельзя было изменять.

После этого я начал экспериментировать с dd.

Весь вопрос для меня еще в том, что я не понимаю, как ORACLE использует сырой диск, когда не полностью его заполнил. Как он заполняет пространство внутри сырого диска? Последовательно или ...

В итоге всех экспериментов, как я уже говорил, я сделал RMAN'овский бекап. Затем удалил расширенный вольюм со всеми его плексами, сабдисками, создал новый, и накатил бекап обратно. Все прекрасно работает!

Кстати я не мог оставить 68Гб для вольюма потому что на сервере разработчиков, куда происходит mirroring плексов нет в ближайшие 2 месяца нет лишних 4ГБ, пока не закупят диски. Поэтому надо было просто как-нибудь вернуть все обратно.
Вот такая ситуация.





Еще некоторые мысли прислали мне по почте знакомые.

Соображения такие:

В оракловском формате сырого диска в заголовках должен указываться размер этого диска - и он, очевидно, не менялся, а значит, Оракл по прежнему работает с ним как 64 Гб, т.. на добавленное пространство он не полезет.

Вариантов можно предложить несколько, но нет у меня четкой 100% уверенности, что ничего не случится - нет такого опыта.

Можно создать еще один диск в 64Гб, командой dd ливануть на нее копию диска

так банально и долбить
dd if=/dev/vgABC/lvolORIG of=/dev/vgABC/lvolNEW bs=1024k

поскольку у нового диска размер 64 Гб - то на него перельется ровно содержимое оригинального "нерасширенного" диска - а затем заюзать именно его вместо прежнего.

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

Можно обрубить обратно увеличенный диск - отрубить добавленный субдиск -
ведь оракл все едино им не пользуется. (Страшно, да? Мне тоже...)

Можно ничего не трогать, жить с увеличенным диском, а на сервере, куда
будет проходить репликация, в качестве мишени задействовать аналогичный
увеличенный диск (68 Гб?) просто на всякий случай.

в худшем случае - пропадет 4Гб дискспейса - не будет использоваться...
10 май 06, 15:17    [2648195]     Ответить | Цитировать Сообщить модератору
 Re: Raw диск, VxFS, ORACLE.  [new]
pi-iv
Member

Откуда:
Сообщений: 10
Кстати, насчет RAW. А разве это не есть сырой диск? Я наверное не совсем корректно написал, но файловую систему на веритасовском вольюме я не создаю, а ораклу указываю его как устройство.
10 май 06, 15:25    [2648252]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить