Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: Обоснование выбора СУБД  [new]
Apex
Member

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

Apex
грязные страницы в этом случае СУБД скидывает?


Не понял вопрос.

Checkpoints and the Active Portion of the Log
The active log must include every part of all uncommitted transactions. An application that starts a transaction and does not commit it or roll it back prevents the Database Engine from advancing the MinLSN.

Это касательно лога. А грязные страницы сбасываются при чекпоинте или кэш обязан пухнуть вместе с логом?
26 ноя 07, 10:56    [4961806]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

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


Мне, кажется, что я приводил ссылку на то, что происходит при чекпоинте.
26 ноя 07, 11:02    [4961841]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
2pkarklin
да нельзя там сравнивать, у мс есть набор "сделай сам" с сильно кастрированом функционалом.
покажите мне продукт сравнимый с этим:
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/toc.htm


Yo.!, ну не стоит таких категоричных выводов!!! Вы же совершенно не в курсе объема функционала MS Analysis Services, MS Integration Services и MS Reporting Services - составнях частей BI от Microsoft. Перечень пунктов документации по этим прожуктам будет не меньше приведенных Вами.
26 ноя 07, 11:07    [4961871]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Yo.!
Guest
pkarklin

Yo.!, ну не стоит таких категоричных выводов!!! Вы же совершенно не в курсе объема функционала MS Analysis Services, MS Integration Services и MS Reporting Services - составнях частей BI от Microsoft. Перечень пунктов документации по этим прожуктам будет не меньше приведенных Вами.

как раз по объему функционала МС я как-то больше просвещен, чем по продуктам Sibel. в вашем наборе "сделай сам" еще как минимум не хватает MS publisher и наверника напильника :)
ладно, раз уж мы выяснили, что с OLAP у оракла SE как минимум не хуже (а OLAP option EE редакции так гораздо лучше) у меня предложение все же вернутся к нашим mssql и oracle, например к бэкапам. я так и не услышал ответа на счет востановления одного блока, можно урл на подробности, а то я не понял какое отношение к этому имеет файловые группы ?
26 ноя 07, 12:05    [4962254]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
как раз по объему функционала МС я как-то больше просвещен, чем по продуктам Sibel. в вашем наборе "сделай сам" еще как минимум не хватает MS publisher и наверника напильника :)


Ну, ну... Ехидничайте. ;) Рынок давно уже "проголосовал" кошельком.

Yo.!
я так и не услышал ответа на счет востановления одного блока, можно урл на подробности, а то я не понял какое отношение к этому имеет файловые группы ?


Файловые группы упоминались мной в контексте восстановления отдельной таблицы. На счет блока: Performing Page Restores
26 ноя 07, 12:52    [4962584]     Ответить | Цитировать Сообщить модератору
 Re: Обоснование выбора СУБД  [new]
Apex
Member

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

Похоже наша дискуссия заходит в тупик.
Итак, все началось с того, что я прицепился к мгновенности операции отсоединения бд, поскольку и правда не знал, что при этом происходит и исренне полагал, что СУБД при этом сбросит согласованные на момент отключения данные в файлы.
Но Вы сказали, что это не так, посмольку в этом нет необходимости, т.к. есть лог.
pkarklin
Apex

И все это происходит мгновенно? А как на счет сброса согласованных данных в файл? :)



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

ОК. Нет проблем, вроде бы все встало на свои места. Но YO отвесил следующий коментарий
йо
т.е. аттач потом вынужден востанавливать вырубленую на ходу бд ... забавное решение, даже для МС
Не будем придираться к остальным выражениям, ключевой момент здесь ВОССТАНАВЛИВАТЬ. Действительно, зачем же еще нужно переносить лог вместе с остальными файлами бд, а для того, чтобы восстанавливать. Но
pkarklin
...эмоции поскипаны...
Аттач ни чего не восстанавливает, ибо восстанавливать нечего.

Как же это восстанавливать нечего, если сброс грязных станиц уже закомиченных транзакицй при отключении не происходит? Зачем же тогда лог?

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

и даже более того
pkarklin
Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.

Такое поведение возможно в двух случаях:
1) При каждом чекпоинте сбрасываются только изменения уже закомиченных транзакций. Страницы которые еще содержат данные незакомиченных транзакций висят в памяти и не сбрасываются даже при чекпоинте. В этом случае при отключении бд и подключении ее без лога, мы сделав запрос и правда можем получить согласованные на какой-то момент в прошлом (до отключения) даные.
2) Грязные страницы любой транзакции (как закомиченной, так и незакомиченной) сбрасываются в файл при очередном чекпоинте. Вопрос: как в этом случае и без лога отличить данные, которые уже зафиксированы, от тех, которые еще были не зафиксированы? Ответ: нужна версионность, например как в FireBird.

Первый вариант - полный идиотизм. Второй вариант не применим к MS SQL, т.к. известно, что она использует блокировочную модель (про юконы сейчас не будем, не о том речь).

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

pkarklin
Мне, кажется, что я приводил ссылку на то, что происходит при чекпоинте.


А написано там следующее
Checkpoint Operation
....
  • Writes all dirty log and data pages to disk.
    ....
  • 26 ноя 07, 13:08    [4962712]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    Apex
    Такое поведение возможно в двух случаях:
    1) При каждом чекпоинте сбрасываются только изменения уже закомиченных транзакций. Страницы которые еще содержат данные незакомиченных транзакций висят в памяти и не сбрасываются даже при чекпоинте. В этом случае при отключении бд и подключении ее без лога, мы сделав запрос и правда можем получить согласованные на какой-то момент в прошлом (до отключения) даные.
    2) Грязные страницы любой транзакции (как закомиченной, так и незакомиченной) сбрасываются в файл при очередном чекпоинте. Вопрос: как в этом случае и без лога отличить данные, которые уже зафиксированы, от тех, которые еще были не зафиксированы? Ответ: нужна версионность, например как в FireBird.

    Первый вариант - полный идиотизм. Второй вариант не применим к MS SQL, т.к. известно, что она использует блокировочную модель (про юконы сейчас не будем, не о том речь).

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


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

    SQL Server 2005 uses a write-ahead log (WAL), which guarantees that no data modifications are written to disk before the associated log record is written to disk. This maintains the ACID properties for a transaction. For more information about transactions and ACID properties, see Transactions (Database Engine).

    To understand how the write-ahead log works, it is important for you to know how modified data is written to disk. SQL Server maintains a buffer cache into which it reads data pages when data must be retrieved. Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database, or the modification must be written to disk so the buffer can be used to hold a new page. Writing a modified data page from the buffer cache to disk is called flushing the page. A page modified in the cache, but not yet written to disk, is called a dirty page.

    At the time a modification is made to a page in the buffer, a log record is built in the log cache that records the modification. This log record must be written to disk before the associated dirty page is flushed from the buffer cache to disk. If the dirty page is flushed before the log record is written, the dirty page creates a modification on the disk that cannot be rolled back if the server fails before the log record is written to disk. SQL Server has logic that prevents a dirty page from being flushed before the associated log record is written. Log records are written to disk when the transactions are committed.
    26 ноя 07, 13:32    [4962895]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3910
    Вы можете объяснить, зачем Вы мне привели эту выдержку из документации? Почему Вы вырвали из контекста мои рассуждения? И как это все-таки соотносится с изначальной поставкой вопроса?
    Еще раз, цитирую сам себя:

    Apex

    pkarklin

    Аттач ни чего не восстанавливает, ибо восстанавливать нечего.

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


    pkarklin
    Если Вы присоедините бд без лога, то запрос вернет данные, которые были на момент отсоединения в файле данных.


    и только потом уже идут мои рассуждения в которых я...гм... что-то упустил?
    -------------------------------------------------------
    Автор благодарит алфавит за любезно предоставленные ему буквы.
    26 ноя 07, 14:21    [4963285]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3910
    Кажется я понял в чем недоразумение... Детач на ходу не делается, так? Все дело в этом?
    -------------------------------------------------------
    Автор благодарит алфавит за любезно предоставленные ему буквы.
    26 ноя 07, 14:32    [4963358]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    Apex
    Детач на ходу не делается, так? Все дело в этом?


    На каком ходу?
    26 ноя 07, 14:44    [4963456]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

    Откуда: Made in USSR
    Сообщений: 3910
    pkarklin
    Apex
    Детач на ходу не делается, так? Все дело в этом?

    На каком ходу?

    Этот вопрос можете проигнорировать:) Это уже меня понесло.

    Что можете сказать про остальное?
    26 ноя 07, 15:17    [4963676]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Yo.!
    Guest
    pkarklin

    Ну, ну... Ехидничайте. ;) Рынок давно уже "проголосовал" кошельком.

    ну правильно, проголосовал и далеко не за МС

    http://www.cnews.ru/news/top/index.shtml?2007/07/02/257161

    Продажи программного обеспечения Business intelligence (BI) в мире выросли в 2006 году на 11,5%, следует из последнего отчета IDC.
    ....
    Основными поставщиками систем BI, согласно данным аналитиков, являются Business Objects, получившая в прошлом году доход в $894 млн., SAS с доходом в $679 млн., Cognos — $622 млн., Hyperion/Oracle — $529 млн., Microsoft — $480 млн.


    2Apex
    вы имхо не стого бока заходите, вам нужно вытянуть с чего это pkarklin решил, что деатач не сбрасывает содержимое буферов в вайлы данных, как это делает любая другая субд, тогда уже открутится от востановления консистентности файлов данных ему не удастся.
    26 ноя 07, 15:26    [4963765]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

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

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

    На самом деле у меня есть подозрение, что грязные страницы (в нашей терминологии блоки) сбрасываются в файлы данных только при коммите. А до коммита удерживаются там и засоряют буферный кэш. Сейчас я пытаюсь выяснить сей момент у знакомых, работающих с MS SQL. Т.к. от господина pkarklin'а развернутого технического коментария не дождешься... впрочем это очень тепично для адептом технологий майкрософта, они очень не любят вдаваться в подробности и копать вглубь.

    P.S. Документация на этот счет тоже не изобилует подробностями... :(
    26 ноя 07, 15:41    [4963900]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    Apex
    На самом деле у меня есть подозрение, что грязные страницы (в нашей терминологии блоки) сбрасываются в файлы данных только при коммите. А до коммита удерживаются там и засоряют буферный кэш. Сейчас я пытаюсь выяснить сей момент у знакомых, работающих с MS SQL. Т.к. от господина pkarklin'а развернутого технического коментария не дождешься... впрочем это очень тепично для адептом технологий майкрософта, они очень не любят вдаваться в подробности и копать вглубь.

    P.S. Документация на этот счет тоже не изобилует подробностями... :(


    Вы даже не потрудились поситать цитату, которую я привел:

    SQL Server maintains a buffer cache into which it reads data pages when data must be retrieved. Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database, or the modification must be written to disk so the buffer can be used to hold a new page. Writing a modified data page from the buffer cache to disk is called flushing the page. A page modified in the cache, but not yet written to disk, is called a dirty page.
    26 ноя 07, 15:47    [4963953]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

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


    Вот эим как раз сейчас и занимаюсь. Чуть пожже сообщу о результатах.
    26 ноя 07, 15:49    [4963961]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Gluk (Kazan)
    Member

    Откуда:
    Сообщений: 9365
    Apex
    На самом деле у меня есть подозрение, что грязные страницы (в нашей терминологии блоки) сбрасываются в файлы данных только при коммите. А до коммита удерживаются там и засоряют буферный кэш.


    Это легко проверить. Даем короткий update, замеряем время commit-а, даем длинный update, сравниваем время commit-а. Если СИЛЬНО отличаются, так оно и есть :)
    26 ноя 07, 15:52    [4963982]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Gluk (Kazan)
    Member

    Откуда:
    Сообщений: 9365
    Кстати, для блокировочника, задерживать грязные страницы в кэше может быть и не так плохо. Ему же не надо держать их в дюжине версий и работает он всегда с текущим состоянием (консистентного чтения на уровне блоков нет, поскольку версионность на другом уровне реализована).
    26 ноя 07, 15:55    [4964001]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Yo.!
    Guest
    Gluk (Kazan)
    Apex
    На самом деле у меня есть подозрение, что грязные страницы (в нашей терминологии блоки) сбрасываются в файлы данных только при коммите. А до коммита удерживаются там и засоряют буферный кэш.


    Это легко проверить. Даем короткий update, замеряем время commit-а, даем длинный update, сравниваем время commit-а. Если СИЛЬНО отличаются, так оно и есть :)

    да вы чо, тогда это была бы не субд. а то прикиньте обновляем данные dwh 10Gb в одной тразакции, и все это все лезет в буфера
    тем более pkarklin уже 2 раза про чекпоинт процетировал ...
    26 ноя 07, 15:59    [4964033]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

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

    Вы даже не потрудились поситать цитату, которую я привел:

    SQL Server maintains a buffer cache into which it reads data pages when data must be retrieved. Data modifications are not made directly to disk, but are made to the copy of the page in the buffer cache. The modification is not written to disk until a checkpoint occurs in the database, or the modification must be written to disk so the buffer can be used to hold a new page. Writing a modified data page from the buffer cache to disk is called flushing the page. A page modified in the cache, but not yet written to disk, is called a dirty page.

    Виноват. Но в таком случае, как же это соотносится с утвержденим о том, что базу можно подключать и без лога, при этом детач не делает чекпоинт, при этом данные в файле консистентны (ваше утверждение о том, что без лога запрос вернет какие-то в прошлом закомиченные данные)? Видимо, без лога данные все же не консистентны? Но при этом, Вы опять же утверждали, что при аттаче никакого восстановления данных в файле не происходит. Так в какой же момент происходит восстановление данных после аттача?
    26 ноя 07, 16:29    [4964302]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

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


    Вот тут я был, конечно, не прав, сказав, что при аттаче не происходит процедура восстановления бд. Она происходит. Во всяком случаи на то есть косвенные упоминания на технете.

    Но не смотря на это, есть и противоположные утверждения, о том, что якобы при отсодинении, все изменения, зафиксированные в логе, применяются к файлу данных. На этом основывается "быстрый способ" усечения лога. Но, боюь, что этот способ вряд ли можно применять со 100% уверенностью.
    26 ноя 07, 16:40    [4964421]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

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

    Вот тут я был, конечно, не прав, сказав, что при аттаче не происходит процедура восстановления бд. Она происходит. Во всяком случаи на то есть косвенные упоминания на технете.

    Но не смотря на это, есть и противоположные утверждения, о том, что якобы при отсодинении, все изменения, зафиксированные в логе, применяются к файлу данных. На этом основывается "быстрый способ" усечения лога. Но, боюь, что этот способ вряд ли можно применять со 100% уверенностью.

    Аминь. Стало быть, если восстановление происходит, то ни о какой мгновенности речи не идет. Речь идет лишь о переносе неких действий с данными (оно же восстановление) во времени, но не об их отсутствии за ненадобность. Так в чем же тогда, приимущество переноса БД в MS SQL перед аналоичным в Oracle? В конпке?

    И еще, Вы, как я полагаю, эксперт по СУБД MS SQL. И как я понял, у Вас возникли трудности в описании данного, важного на мой взгляд процесса, из-за его слабой документированности?

    P.S. А еще было бы интересно узнать, а что же происходит, в описанном Вами случае отсутствия лога? Если есть возможность подключить бд без лога, как же с ней работать?
    26 ноя 07, 17:02    [4964627]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pr0ger
    Member

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

    Если при атаче лог не обнаружен и детач был проведен корректно, то лог пересоздается
    Если при атаче лог не обнаружен и детач не был проведен корректно, то восстановить работу можно только прибегнув к процедуре аварийного пересоздания лога и без гарантии целостности данных в БД. Это процедура уже некое шаманство, Microsoft в данном случае рекомендует восстановить БД из резервной копии.
    26 ноя 07, 17:13    [4964731]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    Apex
    Аминь. Стало быть, если восстановление происходит, то ни о какой мгновенности речи не идет. Речь идет лишь о переносе неких действий с данными (оно же восстановление) во времени, но не об их отсутствии за ненадобность. Так в чем же тогда, приимущество переноса БД в MS SQL перед аналоичным в Oracle? В конпке?


    Причем тут кнопка?! ;) А как же "сложности" c TTS?

    Apex
    И еще, Вы, как я полагаю, эксперт по СУБД MS SQL.


    Никогда не относил себя к экспертам MS SQL! Скажу так - опытный разработчик. Даже на этом форуме есть люди, знающие архитектуру сервера лучше меня.

    Apex
    И как я понял, у Вас возникли трудности в описании данного, важного на мой взгляд процесса, из-за его слабой документированности?


    Не все внутренние процессы сервера документированы. Часто, кроме документации, приходится еще кое-что почитывать.

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


    автор
    CREATE DATABASE ... FOR ATTACH_REBUILD_LOG


    создаст новый лог файл.
    26 ноя 07, 17:14    [4964739]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    pkarklin
    Member

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


    Более того. Сейчас проверил. Checkpoint происходит и при отключении бд и при подключении. Так что в этом плане посыпаю голову пеплом. Так что единственный вариант получения ситуации, когда к файлу не применены все данные из лога - это аварийная остановка. Вот надо еще глянуть, в какой момент происходит и происходит ли удаление неактивной части лога, когда бд имеет FULL модель восстановления. Во всяком случаи при аттаче цепочка бэкапов лога точно будет разорвана.
    26 ноя 07, 17:21    [4964796]     Ответить | Цитировать Сообщить модератору
     Re: Обоснование выбора СУБД  [new]
    Apex
    Member

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

    А как же "сложности" c TTS?

    Дело в том, что перенос базы в MS SQL и перенос табличного пространства в оракле не эквивалентные с концептуальной точки зрения операции. Табличное пространство - это лишь часть БД, а не вся БД (оно может содержать одну или несколько больших таблиц). Оно не содержит метаданных описывающих его. Поэтому необходимо эти метаданные создавать и формировать набор файлов. Кроме того TTS гораздо гибче в данном случае: нет необходимости отстреливать читающие транзакции при переводе переносимого TS в read-only. В MS SQL отключение бд - это отключение в буквальном смысле, вот она была и вот ее нет. Со всеми вытекающими.
    Саму же базу целиком в Оракле перенести не сложнее, чем где бы то ни было: остановили, скопировали, запустили.

    pkarklin

    Не все внутренние процессы сервера документированы. Часто, кроме документации, приходится еще кое-что почитывать.

    Это был скорее камень в огород майкрософта. Тема, имхо, весьма важная, чтобы ее обходить в доке стороной.
    pkarklin

    автор
    CREATE DATABASE ... FOR ATTACH_REBUILD_LOG


    создаст новый лог файл.

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