а вот кому нужен этот кусок...

[YellowMan]

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

Ну по этому конкретному вопросу - оба утверждения не верны.
Рост - контролируемый, спроси ДВА как.
Программно - вполне себе фикситься.
У МС СКЛ есть одна неприятная особенность - кажущаяся простота администрирования, особенно пока база маленькая.

[TYA]

Сообщение от YellowMan

Ну по этому конкретному вопросу - оба утверждения не верны.
Рост - контролируемый, спроси ДВА как.
Программно - вполне себе фикситься.
У МС СКЛ есть одна неприятная особенность - кажущаяся простота администрирования, особенно пока база маленькая.

Ну если так. Оригинальная база порядка 2-3ГБ (может и больше, за давностью не помню). Клиентов ~5000, кот. могут иметь одновременно доступ к данным, ~350000 в целом. Запросы бываю очень сложными... База очень быстро растет до ~80ГБ+ пока на диске есть свободное место, что уже неприлично, за счет лог файла... Рост лог файла не остановить, разве что снести старый и новый завести..., но только ручками ДБА... Насколько я помню, на рабочей базе это не сделать, так что сервис нужно отрубить, а часто это делать - непозволительная роскошь.
Неприятность проявлятся только когда все стоит у клиента, на дому это трудно воспроизвести...
ALTER DATABASE ... MODIFY FILE (NAME = ..., SIZE = XXMB) просто не работает, если ХХ меньше существуещего размера файла. Так что, программного решения нет. Ограничить в размере - перестает работать все, из-за ошибки невозможности пополнить лог. Анлимитед вариант, не рассматривается - см. выше.
Сергей, будь добр, поясни... уже ради спортивного интереса.

[rojer]

Сообщение от YellowMan

Наверное потому что бесплатность молотка фирмы Л - миф

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

ну да всё это уже жёвано-пережёвано...

[YellowMan]

Ну если так. Оригинальная база порядка 2-3ГБ (может и больше, за давностью не помню). Клиентов ~5000, кот. могут иметь одновременно доступ к данным, ~350000 в целом. Запросы бываю очень сложными... База очень быстро растет до ~80ГБ+ пока на диске есть свободное место, что уже неприлично, за счет лог файла... Рост лог файла не остановить, разве что снести старый и новый завести..., но только ручками ДБА... Насколько я помню, на рабочей базе это не сделать, так что сервис нужно отрубить, а часто это делать - непозволительная роскошь.
Неприятность проявлятся только когда все стоит у клиента, на дому это трудно воспроизвести...
ALTER DATABASE ... MODIFY FILE (NAME = ..., SIZE = XXMB) просто не работает, если ХХ меньше существуещего размера файла. Так что, программного решения нет. Ограничить в размере - перестает работать все, из-за ошибки невозможности пополнить лог. Анлимитед вариант, не рассматривается - см. выше.
Сергей, будь добр, поясни... уже ради спортивного интереса.

ОК, для начала - немного занудства.
база никогда сама по себе без нужды не растет - если она растет, то ей так надо. И растет она действительно большей частью за счет логов-что и не удивительно при таком количестве юзеров которые в ней копошаться...и в логе пишуться все эти копошения. Для чего - а для того чтобы ты смор в любой момент откатить базу взад на какой угодно промежуток времени взад...

Если вдруг по какой-то причине тебе это не надо - то для этого есть несколько вариантов: самый простой это установить recovery model базы в simple, но тут ты должен четко представлять что делаешь - при этой модели законченные транзакции не будут писаться в лог и ты сможешь восстановить базу только из последнего бекапа, а не на произвольный момент времени.Программно это вполне можно сделать - ALTER DATABASE рулит.

Если тебя это не устраивает а лог растет - есть волшебная команда BACKUP DATABASE... Кроме всего прочего она снесет указатель конца лога в лог файле на начало файла - лог файл останеться прежнего размера. но расти не будет до тех пор пока там будет хватать свободного места.

Если и бекап тебе неохота делать - пользуй BACKUP LOG...WITH TRUNCATE_ONLY.Эта команда просто сносит указатель конца лога на начало файла - но восстановиться или откатиться потом из этого лога тоже не получиться. По мне в таком случае у клиента проще симпл модел поставить...

Ну и наконец если ты все проделал правильно, команда DBCC SHRINKDATABASE() или DBCC SHRINKFILE() - для лога, поможет тебе вернуть неиспользуемое место взад диску, хотя я бы сильно не рекомендовал это делать.

Вот и все - если в двух словах, то тебе надо:
1. Определиться с рекавери модел
2. Регулярно делать бекап или усечение лога

Все на ура делаеться программно.

[YellowMan]

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

Любой программно-аппаратный комплекс тут - это не вещь в себе а инструмент для решения определенных задач. И при проектировке таких решений бесплатность/не бесплатность системы безусловно играет значение, но далеко не первого и даже не второго порядка.

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

Вот тебе 2 примера - проект, над которым я работаю сейчас, где изначально была сделана ставка на Микрософт и где компания из 6 охломонов выросла в №2 в мире в своей нише, и компания которую я видел с полгода назад - где был выбран Линукс и МайСкул. Когда они достигли лимита этой связки - они оказались у разбитого корыта: уйти под Оракл для них стало безумно дорого и сложно. Людей нет, наработок нет, надо нанимать новых и объяснять им что к чему или переучивать старых и платить дикие деньги за лицензии Ораклу - в итоге они выпали из бизнеса минимум на полгода, потеряли пару очень жирных контрактов плюс конкуренты их обскакали - и все это потому что в начале народ решил съекономить пару рупий на МайСкуле и толковых программерах

[TYA]

Сообщение от YellowMan

Если вдруг по какой-то причине тебе это не надо - то для этого есть несколько вариантов: самый простой это установить recovery model базы в simple, но тут ты должен четко представлять что делаешь - при этой модели законченные транзакции не будут писаться в лог и ты сможешь восстановить базу только из последнего бекапа, а не на произвольный момент времени.Программно это вполне можно сделать - ALTER DATABASE рулит.
...
Все на ура делаеться программно.

Понятно. За пояснения спасибо. Но не simple model была принята без меня и по неизвестным мне причинам. Могу добавить, TRY ... CATCH как раз по теме для runtime для М, почему "нет" - знаю, а переписывать уже существовавшую обработку ошибок... отдельная история.
Дело в том, что дезайн базы и скрипты в основном писались так, что бы было просто портировать между разными ДБМС, ну задача универсализации стояла такая. У М, как всегда своя специфика и с T-SQL, да и еще хромающая. Проблема - осталась.

(Vinod Kumar) Error handling in T-SQL has been in question for quite sometime now in SQL Server 2000. It has not been user-friendly and more often than not most of the developers have had doubts in the way it used to work. Now the good news is in SQL Server 2005 this new feature of “TRY…CATCH” is more like the way it works in many programming language. I have to admit this is the new rich error handling capability for T-SQL world.

Кстати, о совместимости (например):

Oracle 9i supports PL/SQL statement blocks and also can be integrated with Java to execute Java methods. This mechanism is called SQLJ. It implies that Java programmers can write PL/SQL blocks for Oracle and even DB2, Sybase and Informix. It can also execute 3GL routines. On the other hand, SQL Server 2000 can execute blocks of SQL statements called Stored Procedures.

[YellowMan]

Дело в том, что дезайн базы и скрипты в основном писались так, что бы было просто портировать между разными ДБМС, ну задача универсализации стояла такая. У М, как всегда своя специфика и с T-SQL, да и еще хромающая. Проблема - осталась.

TYA, на самом деле если ты хочешь портировать один и тот же _код_ на разные базы - стандарт ANSI SQL-92 твой верный друг и надежный товарищ. Но я надеюсь ты уже знаешь к чему в конце-концов приводят идеи один раз написать код который будет работать всюду, начиная от стиральной машины и заканчивая международной станцией Мир (да-да, это я на Жабу намекаю)? Правильно - такой код даже ессли и будет работать везде, то везде будет работать плохо

Но код - это не администрирование. Администрирование под стандарт не загонишь - поэтому и есть профессия ДВА.

Кстати в стандарте хранимые процедуры описаны, а всякие вкрапления Жавы - нет, поэтому вопрос о том у кого своя реализация далеко не так прост как кажеться. По мне у Оракла намного больше нестандартных примочек и вообще это очень сильно продукт в себе...

[TYA]

Сообщение от YellowMan

Правильно - такой код даже ессли и будет работать везде, то везде будет работать плохо

Даже сомнению не подвергаю, так или иначе оптимизация имеет место... Но к сожалению, в моем случае на практике, очень часто приходилось не оптимизировать, а переписывать для М. "A что делать?"... :D