LINUX.ORG.RU
ФорумAdmin

Добавление пространства к уже примонтированным разделам


0

1

Коллеги, салют!

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

Есть сервер с SLES 11.2 на котором живет oracle 11gR2. Есть директория /u к которой примонтирована партиция в 100 гигабайт, где живет $ORACLE_HOME и директория /db1 в которой живут данные (в ней 500 гб). Все это примаплено из SAN'а (а со стораджами я тем более не дружу). Система тестовая и вот-вот планирует выйти в продакшн, так что теперь нужно эти 500 гб превратить в 2 тб/

Вопрос - как это сделать? gparted не предлагать, сервер перезапускать категорически не рекомендуется (а выход в субботу не оплатят). На сторадже уже увеличили размер нарезки под /db1 до 550 гб, но система, что очевидно это не увидела.

И второй вопрос, если обойти это, и создать из неразмеченной области новый раздел и примонтировать его к, например, /db1/oradata (в котором уже есть данные). Это разумеется возможно. Но данные не пропадут?

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

VS

примонтировать его к, например, /db1/oradata (в котором уже есть данные). Это разумеется возможно. Но данные не пропадут?

Раз в /db1/oradata уже есть данные, то монтировать новый раздел следует в другую директорию.
Странная у вас какая-то разметка. Если уж использовать OFA, то /u01, /u02, /u03 и т.д.

Что, прямо хотите 2 TB одним разделом? Не знаю, конечно, что у вас за SAN и какая нагрузка, но, может стоит размазать по разным LUN'ам индексы и редо-логи?

LVM-то хоть используется?

bigbit ★★★★★
()

но система, что очевидно это не увидела.

resize2fs можно запускать online.

i-rinat ★★★★★
()
Ответ на: комментарий от bigbit

Про лвм: в этом то и проблема, что неизвестно, в ту сторону не копал. Если подскажите как проверить, буду благодарен,

Что есть OFA? Oracle Fusion Architecture? Он там не используется.

Вы предлагается для /db1/oradata/onlinelog свой раздел, для /db1/fra - свой раздел, и т.д.? Не совсем понимаю целесообразность. Прирост производительности?

v_sadist
() автор топика
Ответ на: комментарий от v_sadist

Для начала покажи вывод команды df -h

Да, в основном производительность. Если бэкапы делаются во FRA, я бы ее тоже в отдельный раздел вынес, чтобы нехватка места во FRA из-за скопившихся старых бэкапов не повлияла на БД.

OFA - я имел ввиду Optimal Flexible Architecture

bigbit ★★★★★
()

Система тестовая и вот-вот планирует выйти в продакшн, так что теперь нужно эти 500 гб превратить в 2 тб/

Вот пока она не вышла в продакшн, тебе кровь из носу нужно начать использовать LVM. Или в крайнем случае - создавать ФС на всём диске, без использования разделов. Т.к. изменить на лету размер тома msdos нельзя.

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

Вопрос - как это сделать?

Встречный вопрос: где расположена ФС, которая смонтирована в /db1 ?

Для начала посмотри

df -h /db1
lvdisplay -C
blkid

Всё приводить не обязательно. Достаточно понять, ФС расположена а) на LVM томе б) на всём диске в) на msdos томе.

router ★★★★★
()

И второй вопрос, если обойти это, и создать из неразмеченной области новый раздел и примонтировать его к, например, /db1/oradata (в котором уже есть данные). Это разумеется возможно. Но данные не пропадут?

Опять же зависит от того где расположена ФС. И разумеется, создавать новый том нужно аккуратно, предварительно записав где был предыдущий.

router ★★★★★
()

Кстати, если ты DBA, возможно тебе Oracle ASM подойдёт больше чем LVM, но его тоже нужно грамотно настроить

router ★★★★★
()
Ответ на: комментарий от router

2router и всем всем всем

servername:~ # df -h /db1 Filesystem Size Used Avail Use% Mounted on /dev/mapper/360050768028105918000000000000003_part1 493G 213G 256G 46% /db1 servername:~ # lvdisplay -C servername:~ # blkid /dev/sdb1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3» /dev/sda1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» /dev/sda2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» /dev/sda3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» /dev/sdc1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» /dev/mapper/360050768028105918000000000000003_part1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3» /dev/sdd1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» /dev/sdd2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» /dev/sdd3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» /dev/sde1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3» /dev/sdf1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» /dev/sdg1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» /dev/sdg2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» /dev/sdg3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» /dev/sdh1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3» /dev/sdi1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» /dev/sdj1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» /dev/sdj2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» /dev/sdj3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» /dev/sdk1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3» /dev/sdl1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» /dev/mapper/360050768028105918000000000000000_part1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» /dev/mapper/360050768028105918000000000000000_part2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» /dev/mapper/360050768028105918000000000000002_part1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» /dev/mapper/360050768028105918000000000000000_part3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» servername:~ #

«Кстати, я категорически не рекомендую делать из тестовой системы продуктив. Мухи отдельно, котлеты отдельно. Продуктив должен разворачиваться с нуля и не иметь ничего общего с тестовыми средами.»

Должно быть я немного неправильно изъяснился :) Система уже работает в продакшоне, но поскольку пока в пилотной эксплуатации, ломать ее пока можно (но только пока). Как только все шаги проекта будут завершены система должна будет функционировать 24/7 с возможной остановкой не более 30 секунд (для этого есть standby).

«Да, в основном производительность. Если бэкапы делаются во FRA, я бы ее тоже в отдельный раздел вынес, чтобы нехватка места во FRA из-за скопившихся старых бэкапов не повлияла на БД.»

Спасибо за подсказку, идея хорошая. А что если временно слить данные, сделать раздел, примонтировать к тому же /db1/oradata, затем восстановить данные в уже новый раздел?

Про ASM уже думал, но на то, чтобы купить, изучить, развернуть, настроить уйдет очень много времени. (у нас не куплен grid infrastructure)

v_sadist
() автор топика
Ответ на: комментарий от v_sadist
servername:~ # df -h /db1
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/360050768028105918000000000000003_part1 493G 213G 256G 46% /db1

servername:~ # lvdisplay -C
servername:~ # blkid
/dev/sdb1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3»
/dev/sda1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2»
/dev/sda2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap»
/dev/sda3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3»
/dev/sdc1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3»
/dev/mapper/360050768028105918000000000000003_part1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3»
/dev/sdd1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2»
/dev/sdd2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap»
/dev/sdd3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3»
/dev/sde1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3»
/dev/sdf1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3»
/dev/sdg1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2»
/dev/sdg2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap»
/dev/sdg3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3»
/dev/sdh1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3»
/dev/sdi1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3»
/dev/sdj1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2»
/dev/sdj2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap»
/dev/sdj3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3»
/dev/sdk1: UUID=«5237f81e-2cdd-41f8-b6bd-2bd657396680» TYPE=«ext3»
/dev/sdl1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» 
/dev/mapper/360050768028105918000000000000000_part1: UUID=«f541808b-7d5c-4aef-af32-25bbfddfe8e5» TYPE=«ext2» 
/dev/mapper/360050768028105918000000000000000_part2: UUID=«4f6865c8-2138-4bba-9695-d42b6aa4cef6» TYPE=«swap» 
/dev/mapper/360050768028105918000000000000002_part1: UUID=«ed3344bd-3ccb-4902-a654-e00b5b47b124» TYPE=«ext3» 
/dev/mapper/360050768028105918000000000000000_part3: UUID=«93c361bb-8cdc-4c4e-9410-f41d4e523486» TYPE=«ext3» 
servername:~ #

Внимание: прочитайте описание разметки LORCODE

bhfq ★★★★★
()
Ответ на: комментарий от v_sadist

Мда, LVM-ом тут и не пахнет, везде DOS-разделы.
Это кто вам так сделал - не IBM случайно (судя по вендору СХД)?

# rescan-scsi-bus.sh --forcerescan
# /etc/init.d/multipathd restart
После этого в dmesg должно появится сообщение типа «detected capacity change», и ОС должна распознать новый размер девайса (проверить можно multipath -l).
Но таблица разделов останется прежней, поэтому потом надо будет увеличить раздел с помощью fdisk/parted (лучше при отмонтированной ФС), и это вряд ли получится без перезагрузки.
Затем увеличить ФС с помощью resize2fs.

Система уже работает в продакшоне...

Замечание скорее касалось того, что у продашен-системы должны быть не только prod и standby-серверы, но и отдельный тестовый сервер, на котором все и надо тестировать.

А что если временно слить данные, сделать раздел, примонтировать к тому же /db1/oradata, затем восстановить данные в уже новый раздел?

Если все это делать в оффлайне, остановив базу, забекапив/скопировавав дата-файлы, то почему нет... Хотя лучше перейти сразу на LVM. Создать volume-группу (например, oraclevg), и в ней уже нарезать тома.

ASM для одной базы не имеет смысла, ИМХО. Только когда на одном сервер хостятся много баз.

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

почти успех

Все спасибо за комментарии, все решил гораздо проще и скучнее :) Через ГУИ добавил пространство предварительно отмонтировав раздел. Теперь столкнулся с другой бедой. Предварительно добавляли 50 гб на стордже, и эти 50гб добавились к разделу, все отлично.

Теперь мы расширили на сторадже нарезку до 2 тб, и я пытаюсь таким же образом добавить 1.5 тб к разделу, после чего в гуи ловлю ошибку YaST2 error -1021. Прибавление что естесственно не происходит. Гугл про -1021 ничего толкового не разъяснил. Где копать? (с)

v_sadist
() автор топика
Ответ на: почти успех от v_sadist

2 TB - предел для MBR. Попробуй чуть меньший размер или преобразовать в GPT.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.