Вопросы по работе MS SQL Express
Здравствуйте!
Помогите решить проблему такую вот проблему. Есть сторонняя программа, которая пишет в базу через ODBC. В поставке с программой идет MSDE. Своим приложением я получаю данные из этой базы (также через ODBC, только через другой источник, который настроен на эту базу) и по ним строю графики. И настало мне время наступить на грабли:) размер базы в MSDE ограничен до 2 Гб, поэтому через дней 5 запись данных тупо остановилась без всяких предупреждений.
Выискал, что в бесплатных СУБД Microsoft везде есть ограничение, только в MS SQL Express 2005/2008 - на 4 Гб. Предположительно этого хватит на дней 10, но этого все равно мало. Необходимо как-то предоставлять доступ к данным за более длительный период.
Все усложняется тем, что сторонняя программа пишет только ограниченное число записей в одну таблицу (500 тыс. максимум) и, собственно, ограниченное число таблиц (500 максимум).
Сейчас утонул в мануалах по MS SQL и пока другого варианта не придумал, кроме этого:
Стороннюю программу можно настроить так, что данные будут записываться циклично, т. е. когда уже достигнуто заданное количество таблиц, то она начинает снова писать в первую. По расписанию (пусть каждые 10 дней) бэкапить базу. Насколько я понял, каждый раз будет создаваться новое устройство для бэкапа, т. е. он не будет перезаписываться. Потом, если нужно просмотреть какой-либо из бэкапов, приходит администратор, создает новую базу, восстанавливает в нее бэкап. В своем приложении я могу дать возможность перенастроить источник ODBC на другую базу. Таким образом, чтобы просмотреть графики за более длительный срок, оператор должен явно указать другую базу. Отсюда пара вопросов:
1. Возможно ли автоматизировать процесс восстановления бэкапа в новую базу (чтоб админ не приходил)?
2. Возможно ли одним запросом обратиться к нескольким базам, чтоб оператор сам не выбирал?
З. Ы. Если использовать полноценные СУБД (без ограничений на размер базы), то встает вопрос о производительности. Даже с заполненной базой в 2 Гб графики строятся очень долго, то ли алгоритм выборки данных у меня туповат, то ли ODBC медленный. Есть ли смысл переписать приложение под другой интерфейс доступа, например, под OLE DB?
Помогите решить проблему такую вот проблему. Есть сторонняя программа, которая пишет в базу через ODBC. В поставке с программой идет MSDE. Своим приложением я получаю данные из этой базы (также через ODBC, только через другой источник, который настроен на эту базу) и по ним строю графики. И настало мне время наступить на грабли:) размер базы в MSDE ограничен до 2 Гб, поэтому через дней 5 запись данных тупо остановилась без всяких предупреждений.
Выискал, что в бесплатных СУБД Microsoft везде есть ограничение, только в MS SQL Express 2005/2008 - на 4 Гб. Предположительно этого хватит на дней 10, но этого все равно мало. Необходимо как-то предоставлять доступ к данным за более длительный период.
Все усложняется тем, что сторонняя программа пишет только ограниченное число записей в одну таблицу (500 тыс. максимум) и, собственно, ограниченное число таблиц (500 максимум).
Сейчас утонул в мануалах по MS SQL и пока другого варианта не придумал, кроме этого:
Стороннюю программу можно настроить так, что данные будут записываться циклично, т. е. когда уже достигнуто заданное количество таблиц, то она начинает снова писать в первую. По расписанию (пусть каждые 10 дней) бэкапить базу. Насколько я понял, каждый раз будет создаваться новое устройство для бэкапа, т. е. он не будет перезаписываться. Потом, если нужно просмотреть какой-либо из бэкапов, приходит администратор, создает новую базу, восстанавливает в нее бэкап. В своем приложении я могу дать возможность перенастроить источник ODBC на другую базу. Таким образом, чтобы просмотреть графики за более длительный срок, оператор должен явно указать другую базу. Отсюда пара вопросов:
1. Возможно ли автоматизировать процесс восстановления бэкапа в новую базу (чтоб админ не приходил)?
2. Возможно ли одним запросом обратиться к нескольким базам, чтоб оператор сам не выбирал?
З. Ы. Если использовать полноценные СУБД (без ограничений на размер базы), то встает вопрос о производительности. Даже с заполненной базой в 2 Гб графики строятся очень долго, то ли алгоритм выборки данных у меня туповат, то ли ODBC медленный. Есть ли смысл переписать приложение под другой интерфейс доступа, например, под OLE DB?
Вобщем, кому интересно, рассказываю чего добился, а чего нет. Установил MS SQL 2008 Express. Решил вопрос о производительности следующим образом:
Добавил в базу таблицу info с двумя столбцами: в первом содержатся имена таблиц, во втором - дата и время их создания.
Сделал DDL-триггер, который при создании новой таблицы делает соответствующую запись в info. Теперь при построении графиков не нужно перебирать все таблицы, по info определяю нужные и слепливаю один запрос для этих таблиц с помощью UNION. Скорость увеличилась в разы.
Насчет восстановления бэкапа пока ничего, кроме админа, не придумал. Кроме того, на момент создания бэкапа разрастается журнал транзакций. Поэтому для восстановления требуется до фига места на диске под этот журнал, хотя на самом деле он пустой при простой модели восстановления (как я понял). Обрезать-то его можно с помощью shrink, но как это сделать автоматом до бэкапа?
Добавил в базу таблицу info с двумя столбцами: в первом содержатся имена таблиц, во втором - дата и время их создания.
Сделал DDL-триггер, который при создании новой таблицы делает соответствующую запись в info. Теперь при построении графиков не нужно перебирать все таблицы, по info определяю нужные и слепливаю один запрос для этих таблиц с помощью UNION. Скорость увеличилась в разы.
Насчет восстановления бэкапа пока ничего, кроме админа, не придумал. Кроме того, на момент создания бэкапа разрастается журнал транзакций. Поэтому для восстановления требуется до фига места на диске под этот журнал, хотя на самом деле он пустой при простой модели восстановления (как я понял). Обрезать-то его можно с помощью shrink, но как это сделать автоматом до бэкапа?
артем, а зачем такие странные телодвижения? почему бы не запользовать бесплатные субд? безо всяких ограничений.
Дело в том, что самое главное ограничение здесь в той системе, которая пишет историю (SIMATIC WinCC flexible 2005 от Siemens): предельное число записей на одну таблицу. После заполнения одной таблицы создается новая и в нее продолжается запись, и так до тех пор, пока не будет достигнуто определенное кол-во таблиц. Затем первая удаляется и создается вновь, потом вторая и т.д. С этим ничего не поделаешь, и от этого возникают извращенные алгоритмы для выборки данных. Если бы все писалось непрерывно, то не было б этого гемора: одним элементарным запросом считал данные - и все.
А другие СУБД я предлагал, например, Firebird, но начальство отказалось, мол, все-таки промышленный объект, хотят чего-то понадежнее. Ну и к тому же вопрос о размере так остро уже не стоит - 4-х Гб хватает где-то на недели 2, заказчика это вроде устраивает. То есть это устраивает оператора, а для просмотра долгосрочной истории все-таки получается нужен админ. И еще: с большой заполненной базой при перезапуске система начинает значительно тормозить, т.е. очень долго идет "инициализация архивов", в это время (минут 15) параметры не попадают в базу. Не знаю, почему это происходит, то ли особенности ODBC, то ли WinCC. Так что думаю бОльшую базу держать не имеет смысла.
А другие СУБД я предлагал, например, Firebird, но начальство отказалось, мол, все-таки промышленный объект, хотят чего-то понадежнее. Ну и к тому же вопрос о размере так остро уже не стоит - 4-х Гб хватает где-то на недели 2, заказчика это вроде устраивает. То есть это устраивает оператора, а для просмотра долгосрочной истории все-таки получается нужен админ. И еще: с большой заполненной базой при перезапуске система начинает значительно тормозить, т.е. очень долго идет "инициализация архивов", в это время (минут 15) параметры не попадают в базу. Не знаю, почему это происходит, то ли особенности ODBC, то ли WinCC. Так что думаю бОльшую базу держать не имеет смысла.
Цитата: artem_kvadro
Насчет восстановления бэкапа пока ничего, кроме админа, не придумал. Кроме того, на момент создания бэкапа разрастается журнал транзакций. Поэтому для восстановления требуется до фига места на диске под этот журнал, хотя на самом деле он пустой при простой модели восстановления (как я понял). Обрезать-то его можно с помощью shrink, но как это сделать автоматом до бэкапа?
ну вот в общем нарыл статейку:
http://www.sql.ru/articles/mssql/03080101HowToRestoreDB.shtml
там есть упоминание конструкции RESTORE DATABASE, в которой вроде как дофига опций, почитайте по ней маны, может найдете решение для себя. удачи =)