Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
2. Здесь standby не поможет.
Нужно востанавливаться и катить журналы. Можно катить журналы на
standby в ручном режиме но это не чистый standby. Время поднятия системы равна времени наката всех журналов, и standby нельзя использовать ползователям на чтение(информация там не актуальна).


в 10ке есть "recycle bin", я долго не мог понять кому она может понадобится :)
17 авг 04, 16:36    [888062]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
killed
Первый пункт не может отпасть, поскольку ошибки могут быть и на уровне Оракла. Т.е. с точки зрения ОС это может быть вполне корректный блок, с точки зрения Оракла - неконсистентный.


Наступали и на такие грабли. Как правило в это возникает в случае
коллизий в SCSI шине если контроллер не умеет их(колизии) правильно обрабатывать. Помогает замены SCSI кабелей и/или отключение отложенной записи в кеше контролера.
Кстате на FC дисках я с таким не встречался.
С уважением, onstat-
17 авг 04, 16:37    [888068]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Yo!
автор
2. Здесь standby не поможет.
Нужно востанавливаться и катить журналы. Можно катить журналы на
standby в ручном режиме но это не чистый standby. Время поднятия системы равна времени наката всех журналов, и standby нельзя использовать ползователям на чтение(информация там не актуальна).


в 10ке есть "recycle bin", я долго не мог понять кому она может понадобится :)


Я пока не читал концепт на 10-ку, Чем это отличается от обычного
ролбэк сегмента, и какая разница если транзакция закомичена.Как производится чистка корзины. Это новый тип транзакции
в часности для DDL операторов?
Для юзабельности это решение, для производительности - нет.
Я выбираю производительность, как отключить?

С уважение, onstat-

p.s I like informix more then other.
17 авг 04, 16:49    [888129]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Сергей Тихонов
killed
Ну вот навскидку два сценария.
1) Появление bad-блоков.
2) Пользователь по ошибке удалил критичные данные
По первому пункту - отпадает, потому что избыточность в массиве + в современных серьезных стойках есть фича, которая вообще прогнозирует отказы винтов и т.д.
По поводу удаления - ИМХО легче решить на уровне протоколирования изменений критичных данных на триггерах.


"Фантастика на втором этаже"
Вы никогда не видели как умирает контроллер или его начинает глючить а
вместе с ним и весь RAID.
А еще есть такая фитча как "битая память" которая потому сервером БД переносится в файлы БД и привет получаем сorrupted block.
17 авг 04, 17:00    [888184]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
onstat-
killed
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


Ну вот навскидку два сценария.
1) Появление bad-блоков.
2) Пользователь по ошибке удалил критичные данные


1. Дисковый контроллер эти вопросы решает автоматически для каждого диска
если собран массив с избыточной целостностью. На каждом диске для этого есть соответствующий объем резервных блоков.

2. Здесь standby не поможет.
Нужно востанавливаться и катить журналы. Можно катить журналы на
standby в ручном режиме но это не чистый standby. Время поднятия системы равна времени наката всех журналов, и standby нельзя использовать ползователям на чтение(информация там не актуальна).

С уважением, onstat-


1. Контроллер здесь нипричем. Речь об оракловых багах.
2. Поможет, если накатывать логи на стендбай с задержкой по времени. Вопрос сводится к тому, чтобы успеть эту ситуацию обнаружить в эту дельту времени и принять решение о дальнейших действиях.
17 авг 04, 17:01    [888191]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255

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


Ну вообще-то избежать можно установив вычисление checksum, вот только производительность упадет, и обычно это не делают а только тогда когда появляется проблема..
17 авг 04, 17:09    [888233]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
EugeneS


"Фантастика на втором этаже"
Вы никогда не видели как умирает контроллер или его начинает глючить а
вместе с ним и весь RAID.
А еще есть такая фитча как "битая память" которая потому сервером БД переносится в файлы БД и привет получаем сorrupted block.



1.Пользуйтесь правильными контролерами или делайте сохранение конфигурации на дискету.
Мои контроллеры (не FC) хранят свою конфигурацию в служебных секторах диска и замена контроллера происходит прозрачно.
Рекламой заниматься не буду.

2. Как правило к битым блокам базы приводят колизии в SCSI шине, я уже об этом писал. Я думаю у вас память с контролем четности на сервере, если нет, то кто вам виноват, что вы экономите на надежности сервера,
Если это дествительно проблема с RAM то это будет проявляться не
только в битых блоках базы.

с уважением, onstat-
17 авг 04, 17:12    [888253]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
onstat-
EugeneS


"Фантастика на втором этаже"
Вы никогда не видели как умирает контроллер или его начинает глючить а
вместе с ним и весь RAID.
А еще есть такая фитча как "битая память" которая потому сервером БД переносится в файлы БД и привет получаем сorrupted block.



1.Пользуйтесь правильными контролерами или делайте сохранение конфигурации на дискету.
Мои контроллеры (не FC) хранят свою конфигурацию в служебных секторах диска и замена контроллера происходит прозрачно.
Рекламой заниматься не буду.

2. Как правило к битым блокам базы приводят колизии в SCSI шине, я уже об этом писал. Я думаю у вас память с контролем четности на сервере, если нет, то кто вам виноват, что вы экономите на надежности сервера,
Если это дествительно проблема с RAM то это будет проявляться не
только в битых блоках базы.

с уважением, onstat-



1. Ну хорошо глючный драйвер контроллера.
Короче ситуация "развалившийся массив" такая же нормальная внештатная ситуация , хотя и происходит реже чем выход из строя диска.

2. Это было не у меня .. но я потом эту базу поднимал.
17 авг 04, 17:17    [888278]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
1 & 2.

Это все не важно. Если упадет, то бизнесу будет наплевать, что там за глюк был
17 авг 04, 17:24    [888305]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
killed
onstat-


2. Здесь standby не поможет.
Нужно востанавливаться и катить журналы. Можно катить журналы на
standby в ручном режиме но это не чистый standby. Время поднятия системы равна времени наката всех журналов, и standby нельзя использовать ползователям на чтение(информация там не актуальна).

С уважением, onstat-


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


Имненно эту ситуацию я и имел ввиду под но это не чистый standby.

с уважением, onstat-
17 авг 04, 17:35    [888348]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Да он такой же чистый. Вы просто обеспечиваете транспорт + накат скриптами. Для Оракла принципиальной разницы нет.
17 авг 04, 17:42    [888386]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
в терминах оракла это standby и managed standby соответственно.
17 авг 04, 17:44    [888409]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
В терминах может и нет, а в использовании ресурсов,
и скорости востановления работоспособности системы есть,
я просто на это хотел обратить внимание.

С уважением, onstat-

зы В любом случае ко всему нужно подходть взвешенно.
17 авг 04, 18:26    [888554]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Сергей Тихонов
Всем привет.

Итак, условия задачи следующие: нужно построить VLDB. Объем - терабайты.
Кто чего думает? В принципе вариантов два:

  • MSSQL
  • Oracle

    Вот и давайте пообсуждаем плюсы и минусы каждого варианта ;-) .

    ЗЫ
    В случае c Oracle вопрос выбора ОС также открыт...


  • Копий уже поломано не мало, но 1-й вариант(MSSQL) пока так и не обсуждался.
    Позволю себе пару мыслей по этому поводу(для продолжения беседы)
    исходя из обьемов базы

    1. На Win2000AS количество процессоров ограничено 4 мя( О datacenter отделно).
    2. Обьем непрырывно адресуемого пространства RAM 4 Gb.
    3. Количество узлов кластера 2.
    4. Количество логических дисков ограничено буквами алфавита.:)
    5. Datacenter - позволяет обойти практически все эти ограничения
    кроме памяти и логических дисков, что тоже немаловажно.
    Он поставляется только под определенную сертифицированную
    конфигурацию железа(апргрейд затруднен).
    Патчи против всяких там "ползучих гадов" выходят крайне долго.

    6. 64 - разрядную винду в промышленной эксплуатации наверное еще никто не видел, исходя из имперического правила, что на следующую
    версию (платформу) M$ можно переходить только после выхода 3-го сервиспака этот вариант я рассматривать не хочу.

    То есть , как по мне, M$ еще не доросли.......

    С уважением, onstat-
    18 авг 04, 15:20    [890992]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    EugeneS
    Member

    Откуда:
    Сообщений: 1255
    onstat-
    Сергей Тихонов
    Всем привет.

    Итак, условия задачи следующие: нужно построить VLDB. Объем - терабайты.
    Кто чего думает? В принципе вариантов два:

  • MSSQL
  • Oracle

    Вот и давайте пообсуждаем плюсы и минусы каждого варианта ;-) .

    ЗЫ
    В случае c Oracle вопрос выбора ОС также открыт...


  • Копий уже поломано не мало, но 1-й вариант(MSSQL) пока так и не обсуждался.
    Позволю себе пару мыслей по этому поводу(для продолжения беседы)
    исходя из обьемов базы

    1. На Win2000AS количество процессоров ограничено 4 мя( О datacenter отделно).
    2. Обьем непрырывно адресуемого пространства RAM 4 Gb.
    3. Количество узлов кластера 2.
    4. Количество логических дисков ограничено буквами алфавита.:)
    5. Datacenter - позволяет обойти практически все эти ограничения
    кроме памяти и логических дисков, что тоже немаловажно.
    Он поставляется только под определенную сертифицированную
    конфигурацию железа(апргрейд затруднен).
    Патчи против всяких там "ползучих гадов" выходят крайне долго.

    6. 64 - разрядную винду в промышленной эксплуатации наверное еще никто не видел, исходя из имперического правила, что на следующую
    версию (платформу) M$ можно переходить только после выхода 3-го сервиспака этот вариант я рассматривать не хочу.

    То есть , как по мне, M$ еще не доросли.......

    С уважением, onstat-


    Одназначно не доросли.
    А если выудить цену на DataCenter из тестов TPC-C, то так-то вообще надо посылать их в сад, как решение причем целиком.

    http://www.tpc.org/results/individual_results/HP/hp_superdome_win64_exsum_030828.pdf
    Microsoft Windows Server 2003,
    Datacenter edition (64-bit) 1 T2372A opt064 $128,000
    Это для 64 проц. конфигурации

    http://www.tpc.org/results/individual_results/Unisys/unisys_es7000-540_304K_es.pdf
    O/S: Windows 2003 Srvr, Datacenter Edtn,32P, 1yr Lsub. WND2332-TSP 2 1
    $70,224
    для 32 проц

    Таким образом получаем стоимость ОС 128к/64= 2к за процессор.

    Смотрим для Linux
    http://www.tpc.org/results/individual_results/NEC/nec.express5800.1320xd.c5.3.040628.es.pdf

    Для Solaris
    http://www.tpc.org/results/individual_results/Fujitsu/fujitsu_pw2500_20040106_es.pdf
    Multilingual Solaris(TM) 8 2/02 OE Media B23PT40H0H 1 1 100.00
    18 авг 04, 16:10    [891260]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    locky
    Member

    Откуда: Харьков, Украина
    Сообщений: 62034
    >4. Количество логических дисков ограничено буквами алфавита.:)
    это шутка или серъезно? ежели серъезно, то причем тут логические диски и буквы алфавита?
    18 авг 04, 17:36    [891698]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Сергей Тихонов
    Member

    Откуда: Киев
    Сообщений: 787
    onstat-
    Копий уже поломано не мало, но 1-й вариант(MSSQL) пока так и не обсуждался.
    Позволю себе пару мыслей по этому поводу(для продолжения беседы)
    исходя из обьемов базы

    1. На Win2000AS количество процессоров ограничено 4 мя( О datacenter отделно).
    2. Обьем непрырывно адресуемого пространства RAM 4 Gb.
    3. Количество узлов кластера 2.
    4. Количество логических дисков ограничено буквами алфавита.:)
    5. Datacenter - позволяет обойти практически все эти ограничения
    кроме памяти и логических дисков, что тоже немаловажно.
    Он поставляется только под определенную сертифицированную
    конфигурацию железа(апргрейд затруднен).
    Патчи против всяких там "ползучих гадов" выходят крайне долго.

    6. 64 - разрядную винду в промышленной эксплуатации наверное еще никто не видел, исходя из имперического правила, что на следующую
    версию (платформу) M$ можно переходить только после выхода 3-го сервиспака этот вариант я рассматривать не хочу.

    То есть , как по мне, M$ еще не доросли.......

    С уважением, onstat-

    Ну во-первых - процессоров 8 и RAM тоже 8 в Win2000AS по максимуму может быть
    Во-вторых, думаю что на платформу 64-bit уже смотреть можно.
    В-третьих, 2 узла в кластере тут ни при чем, потому как MSSQL - это shared-nothing и только failover-cluster. Проблема не в операционке...

    Выводы (для меня во всяком случае) следующие: пока что я рассматриваю только Oracle вместе с RAC, как СУБД, подходящую для моего проекта...
    18 авг 04, 17:50    [891753]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Сергей Тихонов
    Member

    Откуда: Киев
    Сообщений: 787
    onstat-
    4. Количество логических дисков ограничено буквами алфавита.:)
    Оно то так, но никто не мешает использовать mount points.
    18 авг 04, 17:51    [891761]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

    Откуда:
    Сообщений: 6941
    locky
    >4. Количество логических дисков ограничено буквами алфавита.:)
    это шутка или серъезно? ежели серъезно, то причем тут логические диски и буквы алфавита?


    Любой путь на патформе Виндоуз начинаестя с

    a:\
    b:\
    c:\
    ..
    z:\

    буква это логический диск.
    Каким способом их количество можно зделать больше чем букв в алфавите?


    С уважением, onstat-
    ps речь идет о базе данных больше терабайта, кстате.
    18 авг 04, 17:52    [891770]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Городовой
    Guest
    onstat-
    Сергей Тихонов
    Всем привет.

    Итак, условия задачи следующие: нужно построить VLDB. Объем - терабайты.
    Кто чего думает? В принципе вариантов два:

  • MSSQL
  • Oracle

    Вот и давайте пообсуждаем плюсы и минусы каждого варианта ;-) .

    ЗЫ
    В случае c Oracle вопрос выбора ОС также открыт...


  • Копий уже поломано не мало, но 1-й вариант(MSSQL) пока так и не обсуждался.
    Позволю себе пару мыслей по этому поводу(для продолжения беседы)
    исходя из обьемов базы

    1. На Win2000AS количество процессоров ограничено 4 мя( О datacenter отделно).
    2. Обьем непрырывно адресуемого пространства RAM 4 Gb.
    3. Количество узлов кластера 2.
    4. Количество логических дисков ограничено буквами алфавита.:)
    5. Datacenter - позволяет обойти практически все эти ограничения
    кроме памяти и логических дисков, что тоже немаловажно.
    Он поставляется только под определенную сертифицированную
    конфигурацию железа(апргрейд затруднен).
    Патчи против всяких там "ползучих гадов" выходят крайне долго.

    6. 64 - разрядную винду в промышленной эксплуатации наверное еще никто не видел, исходя из имперического правила, что на следующую
    версию (платформу) M$ можно переходить только после выхода 3-го сервиспака этот вариант я рассматривать не хочу.

    То есть , как по мне, M$ еще не доросли.......

    С уважением, onstat-

    Профессионал сразу заметен и издалека! Не могли бы вы указать ссылку на источник про RAM в 4 Gb и ограничение в 4 процессора для Windows 2000 Advanced Server?
    Заранее спасибо!
    18 авг 04, 17:52    [891773]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Сергей Тихонов
    Member

    Откуда: Киев
    Сообщений: 787
    EugeneS
    Одназначно не доросли.
    А если выудить цену на DataCenter из тестов TPC-C, то так-то вообще надо посылать их в сад, как решение причем целиком.

    http://www.tpc.org/results/individual_results/HP/hp_superdome_win64_exsum_030828.pdf
    Microsoft Windows Server 2003,
    Datacenter edition (64-bit) 1 T2372A opt064 $128,000
    Это для 64 проц. конфигурации
    Эта цифра блекнет на фоне того, сколько надо заплатить за СУБД... ;-))
    18 авг 04, 17:54    [891785]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Сергей Тихонов
    Member

    Откуда: Киев
    Сообщений: 787
    [quot onstat-]буква это логический диск.
    Каким способом их количество можно зделать больше чем букв в алфавите?/quot] Я уже написал - mount points
    18 авг 04, 17:55    [891795]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    Сергей Тихонов
    Member

    Откуда: Киев
    Сообщений: 787
    onstat-
    ps речь идет о базе данных больше терабайта, кстате.

    http://www.microsoft.com/sql/techinfo/administration/2000/rosetta.asp
    18 авг 04, 17:58    [891809]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

    Откуда:
    Сообщений: 6941
    процесоров действительно 8.

    http://www.microsoft.com/windows2000/server/howtobuy/pricing/pricingwindows.asp

    А вот про память я писал

    автор

    2. Обьем непрырывно адресуемого пространства RAM 4 Gb.


    это ровно 2 в степени 32 бит.

    С уважением, onstat-
    18 авг 04, 18:10    [891855]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    EugeneS
    Member

    Откуда:
    Сообщений: 1255
    Сергей Тихонов
    EugeneS
    Одназначно не доросли.
    А если выудить цену на DataCenter из тестов TPC-C, то так-то вообще надо посылать их в сад, как решение причем целиком.

    http://www.tpc.org/results/individual_results/HP/hp_superdome_win64_exsum_030828.pdf
    Microsoft Windows Server 2003,
    Datacenter edition (64-bit) 1 T2372A opt064 $128,000
    Это для 64 проц. конфигурации
    Эта цифра блекнет на фоне того, сколько надо заплатить за СУБД... ;-))


    Я конечно понимаю, что блекнут, но сэкономить 100к никогда не вредно.
    После того как появились тесты на Linux на 32 проц системе, мне очень тяжело найти повод почему я должен использовать не Unix cистему в качестве сервера БД.

    Лично мой выбор, это: Solaris,HP,Linux
    Конечно я бы попробовал OpenVMS, но это такой раритет, хотя насколько я слышал системы c OpenVMS имеют показатели отказоустойчивости повыше чему у кластерных систем или около того.
    18 авг 04, 18:12    [891868]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить