Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
|
|||
|---|---|---|---|
|
#18+
Здрасьте Вам! Надеюсь вскорости стать здесь завсегдатаем... Я - сетевой админ. У нас работает вагон и маленькая тележка самописных приложений на фоксе. Все базы на тваревых серверах. Причем их еще и развивают - нет специалистов, а те что есть - то ли неспособны, толи не хотят переучиваться. Сетка уже давно вешается от всего этого зоопарка, по шее вскользь прилетает мне (благо, хоть руководство с пониманием относится). Выход - либо плодить сервера и сегментировать сетку, либо субж. Я имею довольно большой опыт работы с базами в Access (на уровне написания приложений), и у нас недавно появился один дельфист. Ну и задумали мы субж. Начнем с перевода одной задачки, дабы продемонстрировать преимущества. Вопросы: 1.Как планировать переход? Дело в том, что задачи между собой почти не взаимосвязаны (хотя и родственны), но некоторые из них пользуют общие справочники. Как быть - валить все в одну базу, либо на каждую задачу - по базе? Как тогда быть с общими таблицами? 2.Железо. Пока начнем с MSSQL7.0 (мне легче будет сделать прототип в родном Access) Исходя из первого вопроса, какую конфигурацию дисковой подсистемы посоветуете: сколько устройств, как распределить по ним базы, отказоустойчивость. Желательно не самый навороченный вариант, тк железка под тестовый сервер уже есть, максимум, что сможем выбить - диски. Объемы баз относительно небольшие, так что, выгоднее будет поставить несколько зеркал на мелких винтах, чем 1-2 RAID5 - устройств будет больше при одинаковых затратах(количестве винтов). Спасибо. С уважением, Сергей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2001, 07:02 |
|
||
|
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2001, 08:45 |
|
||
|
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
|
|||
|---|---|---|---|
|
#18+
Если шпаргалка отвечает на поставленные вопросы, то заранее приношу свои извинения. В предыдущем вопросе я, наверное слишком много воды налил и на неконкретный вопрос получил неконкретный ответ... Пример 1: Есть 2 базы, 3 диска. Как их разместить? Ну первый диск под систему, а два других? Базы на один, логи на другой? Или кажлой базе с логами - по диску? А если 2 базы 2 диска? Или 3 базы 3 диска? Пример 2: Есть две задачи на фоксе под дос. Юзают каждая свою базу. Но есть 2-3 таблички с нормативно-справочной информацией (НСИ), которые являются общими для них. Базы небольшие (после нормализации станут еще меньше, такие уж у нас программеры...) - дбф+индексы=1-2Гб (это я поясняю нецелесообразность применения RAID5 - винтов менее 9Гб уже не найти). Принято решение об эксперименте по переходу на кс. 1этап: превод пока одной задачи (проблема с НСИ на этом этапе решаема: засасывать ее на сервер по ночам). По окончании демонстрируем начальству - оно радостное, спрашивает у нас потребную конфигурацию боевого сервера, и чего надо для апгрейда тестового, и мы переходим ко второму этапу. 2этап: перевод второй задачи: начинаются вопросы. Таблицы второй задачи добавлять в существующую или делать отдельную базу? Если отдельную, то как быть с НСИ? Ответив на эти вопросы, а также на вопросы из первого примера, мы определяемся с требованиями к дисковой подсистеме боевого сервера. Покупаем боевой сервер и апгрейдим тестовый.... С уважением, Сергей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2001, 02:36 |
|
||
|
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
|
|||
|---|---|---|---|
|
#18+
Вообще-то разделение на базы не мешает выполнять запросы по таблицам из разных баз. Единственное что нельзя - использование ссылочной целостности. В принципе можно всё валить и в одну базу, но будет проблемма в том что получаться слишком большие архивы. Можно например некие взаимосвязанные данные, которые редко меняются хранить в отдельной базе, к ней будут одни требования по архивации, а оперативные данные хранить в другой базе, там будут другие требования. Насчет первого вопроса. Я бы делал на одном диске базы и логи, на другом архивы. Говорят существенно ускоряет производительность если делать данные и индексы на разных дисках. Но на мой взгял это вопрос далеко не первой важности. С приветом Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2001, 06:12 |
|
||
|
Концептуальный вопр. по переходу на кл-сервер (структура баз(ы), железка и пр. )
|
|||
|---|---|---|---|
|
#18+
На первый вопрос можно дать ответ однозначный: файл данных и файл логов лучше разместить на двух разных дисках (а ещё, для ускорения, TEMPDB - на третьем диске). По второму вопросу - можно по разному, дело вкуса и других факторов. В данной ситуации, учитывая что задачи всё-таки связаны (хотя бы через справочники), я предпочёл бы разместить все таблицы в одной базе. А разделение на разные задачи сделать на уровне клиентского приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2001, 06:28 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32015859&tid=1825226]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 331ms |

| 0 / 0 |
