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


Ну нет в MS SQL таблспейсов, нету. Есть базы данных, файловые группы, фалы, страницы. Все это можно бэкапить и ресторить. В том числе частично. В том числе раскидывать по разным дискам в не зависимости от того, где что находилось на источнике.

Слушайте, мож мне ссылочку на доку привести, дабы вы хоть сиснтаксис BACKUP\RESTORE посмотрели? Дабы хотя бы ключевые моменты увидеть. Здесь, даже синтаксис приводить - много места надо.


вы начинаете скакать, бэкап/рестор - совсем другая песня, у нас тут деатач/атач vs RMAN DUPLICATE, начать наверно мложно отсюда:
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmdupdb.htm#BRADV89931
21 ноя 07, 16:25    [4946109]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
так у mssql standby даже read only нельзя юзать, или я что-то пропустил ?


Можно.

Yo.!
по остальному попозжей


Я тоже. ;)
21 ноя 07, 16:25    [4946110]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
так прямее сыла:
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmdupdb.htm#i1008537
21 ноя 07, 16:28    [4946133]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin

Не, ну я не мозахист. Договоримся так, у меня есть доступ к сиквел серверу по TCP\IP + утилита командной строки sqlcmd.

Вот видите, Вы это назвали мазохизмом, а йо так вообще не заметил усложнения:) Все относительно:)
pkarklin

автор
+ вопрос по поводу "мгновенно", что происходит когда вы делаете отсоединение файлов в MS SQL?


Сервак закрывает базу. Удаляет сведения о ней из системной бд master и "отпускает" файлы. Все.

И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)
21 ноя 07, 16:43    [4946237]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)


Полагаю, Вы не знакомы с физической архитектурой сиквел сервера, ибо тогда бы не возникло такого вопроса. У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.
21 ноя 07, 17:06    [4946425]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
можно ли делать зашифрованый бэкап на лету


В зашифрованну папку на NTFS.

Yo.!
востанавливать конкретный поврежденный блок (не востанавливая весь террабайт базы),


Можно востаннавливать частично файловую группу, файл, страницу. Применимо к бд, имеющих более одной файловой группы. Таким образом, чтобы использовать эту возможность, необходимо планирование размещения объектов. Ну, и конечно Enterprise редакция и Full Recovery Model.

Yo.!
как узнать сколько займет рековери


Вот это я не знаю даже как посчитать на листке бумаги. Если только с использованием явного ограничивабщего значения пропускной способности дисковой системы.

Yo.!
как ограничить и/о которое генерит бэкап, задать уровень паралельности бэкапа,


Это будет возможно только в 2008 версии (менее чем через 100 дней, если срок выпуска не перенесут). Русурс говернер, кстате, включен в ноябрьский CTP5. Щупаем однако... ;)

Yo.!
быстро востановить случайно удаленую таблицу (drop table),


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

Yo.!
быстро откатить таблицу/бд на 5 минут назад (юзверская ошибка)


Ну, если, опять же эта таблица в отдельной файловой группе - и восстановление "на 5 минут назад" не приведет к неконсистентности бд.
21 ноя 07, 17:15    [4946483]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
pkarklin

Полагаю, Вы не знакомы с физической архитектурой сиквел сервера, ибо тогда бы не возникло такого вопроса. У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.

т.е. аттач потом вынужден востанавливать вырубленую на ходу бд ... забавное решение, даже для МС

по бэкапу - не понял если можно востановить лишь страницу (читай блок на оракловом языке), то при чем кол-во файлов и групп ? и не совсем понятно как планировать, по понятным причинам отгадать где у меня возникнет битая страница я не шмогу ....
по остальному не понял почему вы просто не написали нет, раз уж нет аналогов фичи (прикрутить NTFS к ленте, подожать пару лет, раскладывать каждую табличку по файлгруппам нездоровое занятие даже для майкрософтского дба ).
21 ноя 07, 19:44    [4947285]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Paul Sacks
Member

Откуда:
Сообщений: 1105
peter schmult
Привет!
Сейчас мне нужно сделать обоснование выбора СУБД.. Ищу в интернете инфу, но продвигается как-то туговато. Сам я изучаю сейчас MS SQL Server и работаю с ним, так что в сравнении он должен победить ;)
С областью применения пока ещё не всё ясно, но видимо она будет небольшой, где-то до 30 (наверное) пользователей, с небольшой частотой обновления.
Так вот у меня просьба:
1. Если кто-то писал нечто подобное и не жалко поделиться - был бы очень признателен!
2. Может, кто нибудь мог бы кратко обозначить основные достоинства/недостатки наиболее популярных СУБД, то есть, куда собственно копать? Имеются ввиду MS SQL Server, Oracle, MySQL, FireBird и может быть что-то еще, для массовости..

спасибо!


Бери СУБД только ту, которую сможешь реально "потянуть". В любой организации "изучение" при написании комплексов - считаю смехотворным. Напрмер, у мня 22Гб (109 таблиц) отлично крутится по линуксом на FB.
21 ноя 07, 21:24    [4947473]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin
Apex
И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)


Полагаю, Вы не знакомы с физической архитектурой сиквел сервера, ибо тогда бы не возникло такого вопроса. У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.

Я не знаком с нюансами операции detach:) Стало быть еще и лог надо вместе с файлами переносить... ок:)
21 ноя 07, 22:57    [4947616]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
т.е. аттач потом вынужден востанавливать вырубленую на ходу бд ... забавное решение, даже для МС


Ерунду не несите! Что за термин Вы такой придумали - "вырубленную на ходу"?! Аттач ни чего не восстанавливает, ибо восстанавливать нечего.
22 ноя 07, 08:31    [4948056]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin
Yo.!
т.е. аттач потом вынужден востанавливать вырубленую на ходу бд ... забавное решение, даже для МС


Ерунду не несите! Что за термин Вы такой придумали - "вырубленную на ходу"?! Аттач ни чего не восстанавливает, ибо восстанавливать нечего.
pkarklin ранее

У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.

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

P.S. "вырубленную на ходу" - нормальный такой термин, я его например понял.
22 ноя 07, 10:03    [4948340]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Вы уж определитесь, уважаемый: отсоединенный файл в консистентном состоянии или нет?


Не может бд в MS SQL состоять из одного файла! Понятие консистентность применимо к паре файлов - данные и лог.

Apex
Судя по тому, что Вы сказали ранее, то нет (или как минимум не хватает нескольких транзакций, зафиксированных после чекпоинта)


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

Apex
и для его присоединения необходим лог, из которого потом надо донакатить\откатить изменения не попавшие в файл (он же мгновенно отсоедняется).


Бд присоединяется как минимум из двух файлов. Существует возможность присоединить файл данных и без файла лога (в случаи если он недоступен).

Apex
"вырубленную на ходу" - нормальный такой термин, я его например понял.


"вырубленную на ходу" - это когда шнур питания из сервака выдернули - в моем понятии.
22 ноя 07, 10:12    [4948382]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
2pkarklin

что-то мы вас не понимаем, имхо есть 2 варианта:
1. деатач окуратненько шатдаунит субд, складывая содержимое кеша в файлы данных, оставля их консистентными, тогда можно поднять и без лога
2. вырубить на ходу т.е. моментально, оставив файлы бд в неконсистентном состоянии, которые атач привести в консистентное сможет лишь накатив лог.

вы хотите сказать МС придумала, что-то принципиально новое ?
22 ноя 07, 10:34    [4948526]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
pkarklin
Apex
И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)


Полагаю, Вы не знакомы с физической архитектурой сиквел сервера, ибо тогда бы не возникло такого вопроса. У бд на MS SQL как минимум два файла - файл данных и файл лога (write-a-head) поэтому в любой момент времени, все транзакции, после которых прошел чекпоинт находятся в логе и закомиченные применены к файлу бд, и все транзакции (закомиченные и откаченные) после чекпоинта находятся в файле лога. Поэтому отсоединение бд происходит мгновенно.

Перед отсоединением БД в ней происходит чекпойнт.
22 ноя 07, 10:45    [4948583]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
2pkarklin

с бэкапом и rman мы закончили, я убедил ?
если убедил, можно перейти к стенбаю (log shipping), вчера порылся не смог найти ответы по mssql:

1. передача лога идет асинхронно ? не может возникнуть ситуация, когда транзакция закомитилась, а лог не успел передатся
2. DDL и пользователи/роли тоже копируются автоматом (кажется в репликации это была проблема) ?
3. какие действия нужно провести чтоб в случае краша переключится на standby ? есть ли способ делать переключение автоматом и минимизировать простой ?
22 ноя 07, 10:45    [4948585]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
А6дулла
Member [заблокирован]

Откуда: эврибади нид Someбади
Сообщений: 1733
1, 2, 3...
не надоело парить моск?

об этом и была речь - когда надо отключить, перенести и восстановить, Оракл и его присные начинают тратить время на всякое, потому что там путей сделать это - десятки и для каждого надо помнить исключения и прочую кню.
22 ноя 07, 10:51    [4948620]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
andsm
Перед отсоединением БД в ней происходит чекпойнт.


Нет.
22 ноя 07, 11:00    [4948689]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
2. вырубить на ходу т.е. моментально, оставив файлы бд в неконсистентном состоянии, которые атач привести в консистентное сможет лишь накатив лог.


Почти правильно, за исключением "неконсистентности" в контексте того, что пара файлов и обесечивают консистентность.
22 ноя 07, 11:01    [4948697]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
с бэкапом и rman мы закончили, я убедил ?


Соглашусь, что часть функционала rman возможно реализовать на MS SQL с доп. гемороем, а часть не реализуемо.

Yo.!
1. передача лога идет асинхронно ? не может возникнуть ситуация, когда транзакция закомитилась, а лог не успел передатся

Передаются бэкапы лога. Ассинхронно. Т.е. сценарий: бэкап на источнике - передача - рестор на приемнике. Все это можно делать джобами или утилитой sqllogship.

Yo.!
2. DDL и пользователи/роли тоже копируются автоматом (кажется в репликации это была проблема) ?


Автоматом - ибо это все логгируемые операции. Репликация использует другой механизм.

Yo.!
3. какие действия нужно провести чтоб в случае краша переключится на standby ? есть ли способ делать переключение автоматом и минимизировать простой ?


Вот порядок действий при переходе на standby:

1. Copy any uncopied backup files from the backup share to the copy destination folder of each secondary server.
2. Apply any unapplied transaction log backups in sequence to each secondary database.
3. If the primary database is accessible, back up the active transaction log and apply the log backup to the secondary databases.
4. After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering its secondary database and redirecting clients to that server instance. Recovering puts the database into a consistent state and brings it online.
5. After you have recovered a secondary database, you can reconfigure it to act as a primary database for other secondary databases. For more information, see Changing Roles Between Primary and Secondary Servers.

Автоматизировать можно.

В контексте первого вопроса - если Вам нужна синхронность - то следует использовать Mirroring в синхронном режиме.
22 ноя 07, 11:20    [4948838]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Challenger
Member

Откуда: Москва
Сообщений: 436
Лет 5 назад нужно было протолкнуть INTERBASE вместо MsSQL.
И тогда пришлось родить такой документ.
Не критикуйте фанаты MSSQL. Некоторые моменты при сравнении были высосаны из пальца.
Но IB удалось протолкнуть.
Предлагаю автору действовать по аналогии.

Основные преимущества решений, базирующихся на СУБД Inprise IB Database по
сравнению с решениями на MS-SQL Server.


1. В настоящий момент СУБД IB гораздо дешевле СУБД MS-SQL, а начиная с версии
6.0 СУБД IB будет распространяться бесплатно (платной будет только стоимость
носителя и поддержка). Фирма Microsoft не планирует "локализацию" своего
продукта, тогда как Inprise объявила 3 февраля 2000 года о выпуске русского
дистрибутива сервера баз данных IB DataBase 5. Русский дистрибутив (Media Kit)
IB DataBase 5 включает полный пакет печатной документации на русском языке:
- Описание применения (Operations Guide)
- Руководство по созданию баз данных (Data Definition Guide)
- Руководство по языку (Language Reference)
- Руководство по интерфейсу IB DataBase API (API Reference)
- Руководство программиста (Programmers Guide)
что облегчает сопровождение БД в условиях эксплуатации, а также CD с
программами установки:
- IB DataBase 5.6 for Linux
- IB DataBase 5.6 for Windows 95/98/NT
- IB DataBase 5.6 for Sun Solaris
- IB DataBase 5.6 for Novell Netware 4.2/5.0
- IB DataBase 5.5 для HP-UX 10.20.

2. IB существует на основных платформах, используемых операторами связи - Unix,
Novell и Windows NT. Базы данных, разработанные в IB для одной платформы,
автоматически переносятся под IB на другую платформу. Кроме того, благодаря
тому, что язык IB SQL практически на 100% соответствует стандарту ANSI SQL-92,
базы данных IB относительно легко переносятся на другие сервера баз данных.
Что касается СУБД MS-SQL Server, то в силу ее сильной интегрированности с
операционной системой, применение MS-SQL ограничивается платформой Windows NT.
Из-за серьезных отличий языка Transact-SQL от стандарта SQL-92 перенос баз
данных MS-SQL в формат других БД-серверов без больших усилий по изменению
структур БД и переводу логики обработки на другой диалект SQL невозможен.
Многоплатформенность IB позволяет легко масштабировать сервер БД в том числе и
путем переноса на другую платформу, в то время как MS-SQL жестко привязан к
Windows NT.

3. Для нормального функционирования MS-SQL Server требуется гораздо больше
ресурсов по сравнению с IB. Прежде всего это относится к оперативной памяти
(общепризнанный минимум 128 Mб для версии 7.0). Полная версия MS-SQL Server,
начиная с версии 7.0, устанавливается только на Windows NT Server 4.0, при этом
крайне желательно, чтобы на данной машине более никаких других процессов не
запускалось (выделенный сервер БД). В свою очередь, IB обладает гораздо меньшими
требованиями к ресурсам, прекрасно функционирует на Windows NT WorkStation 4.0
и сервер БД может быть совмещен с сервером управления, используемым
одновременно для организации рабочего места телефониста (администратора,
техника).

4. В отличие от MS-SQL, IB изначально разрабатывалась для применения в системах
реального времени. Для использования в СТК MS-SQL неприменим вообще, т.к. не
анонсирован производителем как система реального времени, а СТК обязано таковой
являться.

5. При объеме баз данных до 2 Гб (БД наших заказчиков для систем на 8 цифровых
2-х Мб потоков на сегодняшний день не превышают 200Мб) при прочих равных
условиях IB обладает большей производительностью по сравнению с MS-SQL. Тесты
показывают разницу от двух до десятков раз.

6. Доступ к БД MS-SQL может осуществляется с использованием средствами BDE,
ODBC или ADO. По производительности и надежности эти средства доступа к данным
значительно уступают прямому доступу к объектам БД в IB. Даже из Visual C++,
"родного" компилятора фирмы Microsoft, доступ к MS-SQL реализуется через ODBC,
что работает очень медленно.

7. По сравнению с IB, у MS-SQL имеется ряд конструктивных недостатков, сильно
осложняющих реструктуризацию базы данных, программирование ее логики, что в
конечном итоге приводит к общей потере производительности системы как при
работе, так и в процессе обновления:
- отсутствует возможность изменения типов столбцов таблицы, удаления
столбцов;
- отсутствует понятие домена (включенное в стандарт SQL-92), заменяющий
его механизм – типы определенные пользователем – не реализует всю мощь
доменов, необходимую при глобальном изменении типа данных;
- отсутствует механизм триггеров семейства «До действия» (BeforeInsert,
BeforeDelete, BeforeUpdate), что делает программирование логики сервера
БД менее гибким;
- отсутствует возможность параллельного выполнения двух и более запросов на
выборку (Fetching) данных.

8. В IB реализован механизм многоверсионности данных, что позволяет обойтись
без блокировки записей при одновременном доступе. В MS SQL блокировки записей
создают значительные проблемы при большом числе одновременных запросов к одной
таблице.

9. Из-за наличия громоздких механизмов настройки MS-SQL намного сложнее в
эксплуатации и администрировании. При этом значительная часть возможностей
MS-SQL, таких как доступ к базе через Internet (это есть и в IB c ver 5.5),
электронная почта, сопряжение с офисными приложениями и т.д. является редко
используемыми.


Выводы:

Для обеспечения работы комплекса СТК с одними и теми же параметрами
реализация БД на основе СУБД IB является более предпочтительной по параметрам
цена/надежность/производительность/масштабируемость/удобство для персонала.

22 ноя 07, 11:40    [4949005]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
2pkarklin

Ок, значит и тут оракл далеко впереди. Oracle data guard умеет и синхронно передавать и с задержкой и на другие архитектуры (недоступные МС) и давать тестовой команде писать на стендбай, потом откатывать написаное и синхронизировать с основной, записывать нагрузку и "проигрывать" ее на другом сервере и наверно еще много всякого ...
Что касается Mirroring то и тут оракл далеко впереди:
http://triffids.googlepages.com/dataguardvsmirroring

ЗЫ. про консистентность, так можно договорится, что крашнутая база в принципе тоже консистентна т.к. на ней выжил лог который в паре с бэкапом на ленте консистентен
ну да ладно, вроде всем понятно о чем идет речь ...
22 ноя 07, 12:14    [4949267]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Yo.! wrote:
> Ок, значит и тут оракл далеко впереди. Oracle data guard умеет и
Оракл настолько далеко ушел вперёд, что кастомеры просто за ним не успевают.
Посему они вынуждены бросать 10.2.1 и мигрировать на убогий 2к5 :(

Posted via ActualForum NNTP Server 1.4

22 ноя 07, 12:24    [4949330]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
locky


Оракл настолько далеко ушел вперёд, что кастомеры просто за ним не успевают.
Посему они вынуждены бросать 10.2.1 и мигрировать на убогий 2к5 :(
Posted via ActualForum NNTP Server 1.4

мне ткнуть носом в отчеты IDC или Gartner ? плиз, не мешайте технической дискусии ;)
22 ноя 07, 12:30    [4949366]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Yo.! wrote:
> мне ткнуть носом в отчеты IDC или Gartner ? плиз, не мешайте технической
> дискусии ;)

му-ха-ха! Поржалъ!
Вы мну еще в забор ткните - почетаем, чо там написано.
У мну последние года с пол дампы приходють от 10.х, хотя год назад
никому в череп не приходила мысль, что люди могут уходить с 10-ки.
С 7-ки, 8-ки... Ну, 9-ки... это понятно.
Но с 10-ки!!!! Она ж - новье, токмо почти купленная, бабло потрачено,
надо работать - отбивать его!
Так нет, бегут как крысы с корабля :( ;)

Posted via ActualForum NNTP Server 1.4

22 ноя 07, 12:35    [4949399]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
Что касается Mirroring то и тут оракл далеко впереди:


Йес... Круче. Позвольте поинтересоваться, а сколько процентов инсталляций используют сколько функционала Oracle? У мну вот тоже Word стоит, дык я его для печати заявления на отпуск использую, хотя хватило бы и Блокнота, а может то (Word) О-ГО-ГО.

Впрочем как и с большим числом типов индексов. На мой вопрос "а кто практически использовал из этой кучи и сколько типов одновременно и почему было "так много" ответов.
22 ноя 07, 14:02    [4950103]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить