» Microsoft SQL SERVER

Prisoner_of_Ice
Спорить не буду, тем боле не понял о чем -
требования к установке SQL 2012 здесь http://msdn.microsoft.com/en-us/library/ms143506(SQL.110).aspx
2003 хоть х86 хоть х64 - там в списке поддерживаемых нет.

ali1977
Я конечно, каюсь, не обратил внимание на "express".
Соответственно к 2005 express здесь -
http://msdn.microsoft.com/ru-ru/library/ms143680(v=sql.90).aspx
И там нет в списке 64 редакций системы.

Но есть еще sql2008 http://msdn.microsoft.com/ru-ru/library/ms143506(v=sql.100).aspx
и sql2008r2 http://msdn.microsoft.com/ru-ru/library/ms143506(v=sql.105).aspx

И вряд-ли в версии Express стоит заботиться о высокой производительности...

ali1977

Цитата:

что конкретно имеем ввиду?

По поводу express точно не знаю, ставил Enterprise - выбора не было, какая ОСь х64/х86 такой и SQL ставится...

vincome

Цитата:

Существенной разницы в работе 1С8.2 по сравнению с 2008 R2 на аппаратном железе пока не наблюдается .
А вот при виртуализации ведет себя значительно лучше.

В чем это проявляется?

Добавлено:
Стоит пробовать 2012?

Коллеги добрый день, помогите с диагностикой проблемы:

Ссылка
Ссылка
Ссылка
Ссылка

Aroun
1. что за новая мода скрины вываливать такие(мало того что огромные, так еще и беспролезные)
2. где собственно вопрос

там вам четко написано - посмотрите журнал событий. перепечатывать за вас ошибку 1С со скрина нет никакого желания

Цитата:

1. что за новая мода скрины вываливать такие(мало того что огромные, так еще и беспролезные)

Надо было просто написать "ПАМАГИТЕ СРОЧНА!" ?)))

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


Цитата:

так еще и беспролезные

Цитата:

посмотрите журнал событий.

Может ты перед тем как умничать посмотришь третью сверху ссылку и увидишь что там скуля и там близко ничего нет про эту ошибку?

Aroun
рассуждаем логически: журнал винды - чистый, журнал СУБД - чистый. так чего вы хотите? услышать, что надо разбираться с 1С?

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

Мил человек, ты или помоги или не мешай.

Aroun
1.

Цитата:

от спецов

Цитата:

если я решу

вывод - вам не нужно чужое мнение. ведь это еще и вы сами решаете кто спец, при том, что не можете в элементарной ошибке разобраться.
2.1. если бы вы умели читать то что вам пишут, то уже давно бы дошло, что проблема не в SQL
Цитата:

перепечатывать за вас ошибку 1С со скрина нет никакого желания

учитесь пользоваться поиском
2.2. 1С жалуется на недоступность журнала для заданной БД. журналов таких всего 2: журнал логов транзакций(в SQL бы были ошибки) и журнал регистрации(1Совская фигня).

и еще раз: это не проблема SQL сервера, у вас есть служба поддержки 1С вот к ним и надо обращаться в первую очередь.

Хорошо, я понял.

У меня база занимает - 20Гб (mdf+ldf), backup - 200Гб. Уже места не хватает на диске. Что делать? Модель simple. Посоветуйте что-нибудь.

Painted
1. какая база, т.е. что за ПО ее использует
2. за какой промежуток времени необходимо обязательно иметь бэкапы

Prisoner_of_Ice
1. 1С82
2. Бакапим ночью средствами 1С. Но не всегда срабатывает, т.к. сеансы повисшие остаются. Скульный бакап для перестраховки. Храним 1 день.

Painted
1. базу надо регулярно выгружать в dt, удалять скульную базу, создавать новую/пустую и заливать в нее dt. как часто это делать - решать вам. зависит от размеров базы(вообще, это где-то в ИТСках описано подробнейшим образом)
2. если вы храните бэкапы 1 день, а mdf+ldf - 20 гигабайт, то как вам не хватает 200 Гб? это же в 10 раз больше!
3. хранить бэкапы бухгалтерии менее чем за 2е суток - преступление
4. что означает бэкап средствами 1с? выгрузки? если да - то хватит заниматься фигней. делайте бэкап средствами sql и записывайте уже этот бэкап на внешние носители, если действительно переживаете за сохранность информации

Prisoner_of_Ice
1. Спасибо, поищу
2. mdf+ldf - 20 гигабайт, а bak занимает - 200Гб. Потому места и не хватает.
3. Скульный бакап храним 1 день, dt-ки месяцами
4. Переживаем больше, что бакапы средствами SQL занимают по 200Гб. Негде хранить.
Вопрос открытый. Как ужать бакапы созданные SQL.

Painted
ОМГ! используйте full recovery model, конечно! и наймите уже администратора БД!

п.с. при размере база+журнал транзакция в почти 50 гигабайт у меня бэкап суточный 30 гигов всего. спокойно можно хранить за 2е суток бэкапы даже при объеме свободного дискового пространства всего в 100 гигабайт...

Prisoner_of_Ice

Цитата:

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

Выгрузку в dt компания 1С НЕ рекомендует для резервного копирования. Только для перехода файловый-серверный/серверный-файловый.


Цитата:

ОМГ! используйте full recovery model, конечно! и наймите уже администратора БД!

зачем? если компанию устраивает только наличие полного бэкапа?

Painted

Цитата:

2. mdf+ldf - 20 гигабайт

Как-то это оооочень сомнительно. Посмотрите в свойствах базы на SQL Server количество и размер файлов. Возможно у базы есть дополнительные файлы, о которых вы просто не в курсе. Это можно сделать через SSMS (ПКМ на базу, свойства, вкладка файлы), либо запросом:

Код: USE [имяБД]
SELECT name, physical_name, size*8/1024 [Size in MB]
FROM sys.database_files

bigsloth

Цитата:

Выгрузку в dt компания 1С НЕ рекомендует для резервного копирования. Только для перехода файловый-серверный/серверный-файловый.

а теперь прочитайте весь диалог и посмотрите для чего рекомендовалось это сделать. при чем тут вообще резервное копирование, если говорилось об уменьшении размеров БД в SQL

Цитата:

зачем? если компанию устраивает только наличие полного бэкапа?

как минимум по тому, что модель simple использовать на рабочих БД - не айс.

Painted
у меня есть еще такое ощущение, что вы используете database differential для бэкапов. и, судя по всему, вы делаете это не очень правильно...

Prisoner_of_Ice

Цитата:

а теперь прочитайте весь диалог и посмотрите для чего рекомендовалось это сделать.

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

Цитата:

как минимум по тому, что модель simple использовать на рабочих БД - не айс.

Еще раз задам вопрос. Если организацию устраивает возможность восстановления только из последнего полного и последнего диф. бэкапа - зачем им полная модель восстановления?


Цитата:

у меня есть еще такое ощущение, что вы используете database differential для бэкапов. и, судя по всему, вы делаете это не очень правильно...

как можно делать диф. бэкап "не очень правильно"? И как, по вашему мнению, диф. бэкап может быть размером больше чем сама БД? Учитывая, что он из себя представляет всего лишь копии страниц, измененных в файле данных после последнего полного бэкапа (и да, если страница изменялась 100500 раз, она не будет 100500 раз скопирована в диф. бэкап - достаточно ее скопировать один раз).

bigsloth

Цитата:

И если ничего из приведенного выше не помогло, то расскажите как делаете бэкап? Покажите скрипт.

Похоже дело было в скрипте. Удалил старый скрипт и настроил "Задача "Резервное копирование базы данных" интерактивно, bak уменьшился до 13Гб. Такое ощущение что новый бакап накладывался на старый и все хранилось в одном флаконе.

Цитата:

наймите уже администратора БД!

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

Цитата:

модель simple использовать на рабочих БД - не айс

Пользоваться достоинствами модели full я просто не умею. И не уверен, что это нам нужно.

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

Цитата:

нет желания объяснять очевидные вещи, если честно

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

Цитата:

совет непосредственно 1С в одном из ИТС

а еще они советуют выбирать полную модель восстановления и делать BACKUP LOG WITH TRUNCATE_ONLY(слава Богу, уже недоступный в SQL Server 2008 и старше), а так же делать SHRINKDATABASE

Дубль

bigsloth
ладно.
с выгрузкой/загрузкой:
1С очень коряво работает с БД и у них при работе появляется огромное количество "пустых" строк, дублирующихся строк в таблицах. по сути при проведении выгрузки у них весь этот хлам удаляется, и вы загружаете потом "чистую" базу на сервер. согласитесь, что если в таблице 10 000 строк, а в них 20% хлама ненужного, то запросы будут медленнее обрабатываться. ну это в общих чертах.
про simple model:
Ссылка
т.е. на самом деле никто не запрещает ее использовать, но есть минусы типа как потерять информацию о последних изменениях, а так же(что весьма важно с 1С на самом деле) при этом режутся логи транзакций. В нашем случае это не приемлемо, это может привести к падению производительности при работе с БД 1С. модель полного восстановления позволяет избежать всех этих неприятностей + уменьшения размеров лога транзакций происходит безболезненно во время полного бэкапа БД.

собственно это мои соображения по данной проблеме.

Цитата:

1С очень коряво работает с БД

согласен, у меня тоже есть претензии

Цитата:

появляется огромное количество "пустых" строк, дублирующихся строк в таблицах

никогда такого не видел. Точнее дублирующиеся видел на файловых базах, но в этом случае загрузка не проходит, поскольку SQL Server обычно в этих случаях вполне справедливо ругается на попытку вставить в уникальный индекс повторяющееся значение. Если используется клиент-сервер, дублирующихся/пустых строк, возникающих из-за глюков платформы, а не кривых рук программистов - не видел.

Цитата:

если в таблице 10 000 строк, а в них 20% хлама ненужного, то запросы будут медленнее обрабатываться

Нет, далеко не всегда. Это больше зависит от состояния индексов/статистики.

Цитата:

типа как потерять информацию о последних изменениях

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

Цитата:

при этом режутся логи транзакций. В нашем случае это не приемлемо, это может привести к падению производительности при работе с БД 1С.

Вы заблуждаетесь. В нормальной ситуации скорость работы в простой и полной моделях восстановления будет одинаковой, но существует ряд операций (операции с минимальным протоколированием), на которых в простой модели восстановления может быть заметен прирост производительности.
Простая модель восстановления просто ну никак не может быть "медленнее" полной. Скорее наоборот - в полной модели восстановления возможны периодические проблемы с производительностью (особенно когда практикуются "уменьшения размеров лога транзакций", из-за чего ему приходится все время увеличиваться - на время автоприращения журнала транзакций БД становится недоступной на запись, до окончания этой операции).

SQL 2008 R2 x64 - кончился пробный период, куплена версия SQL 2008 R2 x64 для использования совместно с 1С.
Если просто поверх переустановить заработает?

Или тут только вариант удалять и заново устанавливать?

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

Angel_19

Цитата:

Если просто поверх переустановить заработает?

При переустановке в SQL Server Installation Center выбрать Maintenance, затем Edition Upgrade...

Цитата:

Следующие обновления не установлены:
Обновление безопасности для SQL Server 2008 R2 (KB2494088)
Пакет обновления 1 (SP1) Microsoft SQL Server 2008 R2 (KB2528583)
Microsoft .NET Framework 3.0: языковой пакет для систем x86 (KB928416)

У меня SQL Server 2008 R2 стоит на Server 2003х86 R2. В системном журнале гроздь ошибок:
Цитата:

Таймаут (30000 мс) ожидания для подключения службы SQL Server (MSSQLSERVER).

Сбой при запуске службы "SQL Server (MSSQLSERVER)" из-за ошибки Служба не ответила на запрос своевременно.

Служба "Агент SQL Server (MSSQLSERVER)" является зависимой от службы "SQL Server (MSSQLSERVER)", которую не удалось запустить из-за ошибки Служба не ответила на запрос своевременно.

И как следствие
Цитата:

Таймаут (30000 мс) ожидания для подключения службы Агент сервера 1С:Предприятия 8.2.

Теперь ее приходится запускать вручную... непорядок, как исправить? Что делать с обновлениями, или не обновляться?

Цитата:

Сбой при загрузки пакета Среда SQL Server Management Studio Package

Хотел исправить SP1, не получилось, какие-то ссылки на "предыдущие" ошибки. Решил обновить с дистрибутива SQLFULL_RUS.iso, но запускается как английская версия. Почему?