|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
Хотелось бы услышать об опыте применения raw - разделов. Статьи на http://www.oradba.com.ru я читал, но это не опыт применения, этого недостаточно. Интересует практический опыт, конфигурация базы, параметры нагружаемости базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 11:17 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
Если у Вас Linux, то использование raw devices исключит кеширование датафайлов операционной системой и улучшит этим быстродействие. Т.е. основная идея в том, чтоб отдать больше памяти под буферный кеш SGA и кешировать данные только в нем, а кеширование в ОС исключить. Нагрузка на базу тут не причем. Рекомендации по типам файлов, которые лучше размешать на raw (это подразумевает, что датафайлы уже размещены или ваша ОС позволяет Direct I/O на файловой системе) можно найти здесь: http://www.ixora.com.au/tips/ ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 15:14 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
А какие могут быть траблы с обслуживанием? Какие есть отрицательные стороны использования raw? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 15:49 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
>А какие могут быть траблы с обслуживанием? Какие есть >отрицательные стороны использования raw? ну, первое что приходит в голову, то если делать бекап средствами ОС, то надо использовать только dd, а это не совсем удобно с точки зрения каталогизации бекапов. Ну и там есть ньюансы с рекавери, что первые несколько блоков, должны быть пропущены, т.к. реально не принадлежат датафайлу (но это тоже можно сделатьс помощью dd) А так же естественно ваш любимый autoextend работать не будет, ну и там другие манипуляции с размерами файлов (resize) работать не будут, т.к. файл на raw - это просто ссылка на партишин, размерами которого собственно и определяется размер файла. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:11 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
добавлю, что autoextend - это детские игры, несерьезно. И еще ИМХО для Linux пока нет достойной альтернативы raw devices, поскольку нет приличной файловой системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:24 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
А шифрование файловой системы raw в данном случае возможно? Какая вообще в этом случае файловая система? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:26 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
>А шифрование файловой системы raw в данном случае >возможно? Какая вообще в этом случае файловая >система? так в том то и дело, что никакой файловой системы на raw нет. А насчет шифрование, то мне кажется нужен другой сервер (Oracle Labels или как его там) - но не думаю, что люди в здравом уме его используют - это было создано специально для гос.контор. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:41 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
raw devices - это сырые данные, никаких файловых систем нет. Что такое шифрование с помощью файловых систем - я не знаю ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:42 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
2 .dba Уже умеем в унисон петь ... :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:43 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
>Уже умеем в унисон петь ... :-) да, я думаю нас объединяет нелюбовь к autoextend'у :-))) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:46 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
Шифрование поддерживается на уровне файловой системы ext2. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:49 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
"нас объединяет нелюбовь к autoextend'у" А насчёт этого, - чтож, могу вам пожелать только любви и согласия. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 16:50 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
а что шифрует ext2 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 17:05 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
по поводу унисона: просто с разницей в минуту написали тебе практически одинаковый ответ ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 17:06 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
Ничего не имею против унисона, только я не люблю людей которые начинают обьединяться против людей имеющих свою другую точку зрения, пусть и не всегда правильную. Начинают заниматься интригами и прочее. По поводу шифрования: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Что-то примерно так. У меня стоит RH, сам я пока еще ставил. А Suse 7.3 прямо при инсталляции предлагает использовать шифрование. Зря всётаки меня народ не поддержал по организации форума по Linux ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 17:25 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
я все таки не понял, зачем это нужно с точки зрения баз данных? Т.е. операции с файловой системой шифруются, но какая от этого польза?? Плюс, я так понимаю, доп. нагрузка на процессор. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 17:29 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
Да, забыл сказать - это стандартными ядрами RedHat указанные методы шифрования не поддерживается, потомучто по закону США запрещены для экспортирования. A Suse это Европа. А вообще можно взять на http://www.kerneli.org А с точки зрения БД это не нужно и я собственно не говорил что это нужно. Это нужно вообще с точки зрения защиты информации ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 17:31 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
O size raw devices: Redo Log = 1*512 byte block + Redolog size Data File = 2*DBBlockSize + tablespace size Zamechamie: raw devices OBYZANY byt BLOCHNYMY (ne symvolnimy) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 18:55 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
2ShgGena >Redo Log = 1*512 byte block + Redolog size >Data File = 2*DBBlockSize + tablespace size а откуда эти данные. Я как-то проверял наличие заголовков и если мне память не изменяет, то для Linux при бэкапе партиций через dd никаких блоков skip'ать было не нужно. >raw devices OBYZANY byt BLOCHNYMY (ne symvolnimy) по-моему наоборот: Oracle использует только символьные устройства при работе с raw. Можно определить также блочные, но это больше для удобства работы с dd, Oracle их использовать не будет. Поправь, если я ошибаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 22:14 |
|
Хотелось бы услышать об опыте применения raw - разделов
|
|||
---|---|---|---|
#18+
1) razmery: Oracle metalink tips: Implementation of Unix Raw Partitions as Oracle Data files text from tips: When creating the oracle tablespace on the raw partition a slightly smaller size than the actual partition size needs to be specified. This size can be calculated as follows: Size of Redo Log = Raw Partition Size - 1*512 byte block Size of Data File = Raw Partition Size - 2* Oracle Block Size 2) on solaris cluster 3.0 i ne smog sgenerirovat oracle s raw devices poka ne smenil tip s symbol na block oriented. (tip 6) na linux rh advanced server ta ge situaciya. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2002, 23:22 |
|
|
start [/forum/topic.php?fid=52&msg=32073101&tid=1992615]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 150ms |
0 / 0 |