powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
5 сообщений из 5, страница 1 из 1
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
    #32015789
Serge_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здрасьте Вам! Надеюсь вскорости стать здесь завсегдатаем...
Я - сетевой админ. У нас работает вагон и маленькая тележка самописных приложений на фоксе. Все базы на тваревых серверах. Причем их еще и развивают - нет специалистов, а те что есть - то ли неспособны, толи не хотят переучиваться. Сетка уже давно вешается от всего этого зоопарка, по шее вскользь прилетает мне (благо, хоть руководство с пониманием относится). Выход - либо плодить сервера и сегментировать сетку, либо субж. Я имею довольно большой опыт работы с базами в Access (на уровне написания приложений), и у нас недавно появился один дельфист. Ну и задумали мы субж. Начнем с перевода одной задачки, дабы продемонстрировать преимущества.
Вопросы:
1.Как планировать переход?
Дело в том, что задачи между собой почти не взаимосвязаны (хотя и родственны), но некоторые из них пользуют общие справочники.
Как быть - валить все в одну базу, либо на каждую задачу - по базе? Как тогда быть с общими таблицами?
2.Железо. Пока начнем с MSSQL7.0 (мне легче будет сделать прототип в родном Access)
Исходя из первого вопроса, какую конфигурацию дисковой подсистемы посоветуете: сколько устройств, как распределить по ним базы, отказоустойчивость. Желательно не самый навороченный вариант, тк железка под тестовый сервер уже есть, максимум, что сможем выбить - диски. Объемы баз относительно небольшие, так что, выгоднее будет поставить несколько зеркал на мелких винтах, чем 1-2 RAID5 - устройств будет больше при одинаковых затратах(количестве винтов).
Спасибо.
С уважением, Сергей.
...
Рейтинг: 0 / 0
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
    #32015805
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
    #32015846
Serge_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если шпаргалка отвечает на поставленные вопросы, то заранее приношу свои извинения.
В предыдущем вопросе я, наверное слишком много воды налил и на неконкретный вопрос получил неконкретный ответ...

Пример 1:
Есть 2 базы, 3 диска.
Как их разместить?
Ну первый диск под систему, а два других?
Базы на один, логи на другой?
Или кажлой базе с логами - по диску?
А если 2 базы 2 диска? Или 3 базы 3 диска?

Пример 2:
Есть две задачи на фоксе под дос. Юзают каждая свою базу. Но есть 2-3 таблички с нормативно-справочной информацией (НСИ), которые являются общими для них. Базы небольшие (после нормализации станут еще меньше, такие уж у нас программеры...) - дбф+индексы=1-2Гб (это я поясняю нецелесообразность применения RAID5 - винтов менее 9Гб уже не найти). Принято решение об эксперименте по переходу на кс.
1этап: превод пока одной задачи (проблема с НСИ на этом этапе решаема: засасывать ее на сервер по ночам). По окончании демонстрируем начальству - оно радостное, спрашивает у нас потребную конфигурацию боевого сервера, и чего надо для апгрейда тестового, и мы переходим ко второму этапу.
2этап: перевод второй задачи: начинаются вопросы. Таблицы второй задачи добавлять в существующую или делать отдельную базу? Если отдельную, то как быть с НСИ?
Ответив на эти вопросы, а также на вопросы из первого примера, мы определяемся с требованиями к дисковой подсистеме боевого сервера. Покупаем боевой сервер и апгрейдим тестовый....

С уважением, Сергей.
...
Рейтинг: 0 / 0
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
    #32015857
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще-то разделение на базы не мешает выполнять запросы по таблицам из разных баз. Единственное что нельзя - использование ссылочной целостности. В принципе можно всё валить и в одну базу, но будет проблемма в том что получаться слишком большие архивы. Можно например некие взаимосвязанные данные, которые редко меняются хранить в отдельной базе, к ней будут одни требования по архивации, а оперативные данные хранить в другой базе, там будут другие требования.

Насчет первого вопроса. Я бы делал на одном диске базы и логи, на другом архивы. Говорят существенно ускоряет производительность если делать данные и индексы на разных дисках. Но на мой взгял это вопрос далеко не первой важности.

С приветом Сергей
...
Рейтинг: 0 / 0
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
    #32015859
Владимир Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На первый вопрос можно дать ответ однозначный: файл данных и файл логов лучше разместить на двух разных дисках (а ещё, для ускорения, TEMPDB - на третьем диске).
По второму вопросу - можно по разному, дело вкуса и других факторов.
В данной ситуации, учитывая что задачи всё-таки связаны (хотя бы через справочники), я предпочёл бы разместить все таблицы в одной базе. А разделение на разные задачи сделать на уровне клиентского приложения.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]