Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
Доброе время суток всем! Имеется база данных с большой таблицей (на данный момент 150 000 000 записей, ~47 Gb). Данные в таблицу добавляются 1 раз месяц по окончании учетного переиода и не менются (база предназначена для статистического анализа). В свзи с таким объемом появились некоторые неудобства в работе (скажем так) 1. Восстановление с полной резервной копии занимает ~17 часов (создание ~3 часа) - мне кажется не очень приемлемое время в случае сбоя (HP SureStore DLT40). 2. Т.к. периодически приходится очищать таблицу от самого позднего периода (для того, чтобы можно было добавить данные нового периода), то эта операция занимает ~3 часа(таблица само собой блокируется) и сильно загружает сервер После прочтения http://www.osp.ru/win2000/sql/2000/03/311.htm возникли мысли развить предложенные там идеи, а именно разместить данные отдельного учетного периода не только в отдельную таблицу на и в отдельную базу данных . Прежде чем решиться на подобные глобальные изменения, хотелось бы узнать ваше мнение - правильно/неправально ли вообще затевать подобное, с какими проблемами/трудностями возможно придется столкнуться. Да еще планируется установить отдельный сервер с Microsoft Analysis Server-ом для создания cube-ов для этих данных PS 2xPII-733, RAM 1Gb, RAID Controller ADAPTEC 3200S, 3XQUANTUM ATLAS IV 36 RAID5 Win2000Adv SP2, SQL2000 SP1 PPS ответы можно дублировать и на почтовый адрес brylyev@mail.com ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2001, 08:19 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
У меня похожая ситуация: Данные по телефонным звонкам за предидущие периоды сидят в отдельной базе, каждая таблица соответствует отдельному периоду. В рабочей базе есть только данные текущего периода, а также сводные данные по другим периодам. Разница наверное только в том, что доступ к этим данным идет не через view а через хранимые процедуры с использованием UNION ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2001, 09:37 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
2All Неужели никто ничего не может хотя бы посоветовать попробовать , пока база находится в тестовом режиме ? Потом ведь советы будет труднее проверить. Готов выслушать любые советы - лучше погонять пару дней тесты(может быть и бесполезные), чем потом корить себя за очевидные промахи 2victorS У вас, я так понял, 2 базы - оперативные данные и архив. Я же планирую иметь минимум 12 баз (по числу месяцев). Назначали ли вы права пользователям на объекты в обеих базах (т.е. дублировали ли пользователей) или работали через хранимые процедуры ?(на 2-х базах дублировать пользователей еще можно, а во на 12-ти...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 08:10 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
To Glorry! 1 совет. A что, если размещать таблицы с месячными данными не в отдельной базе, а создавать для каждой из них свою filegroup. Там же строить индексы для таблиц. Тогда можно будет восстанавливать не всю базу, а отдельные filegroup. Правда если на сервер потолок упадет, все равно придется делать полный restore. 2 совет. Если данные старых периодов используются только для анализа и не изменяются, то зачем их держать в базе. Создайте OLAP хранилище, после закрытия периода processните все кубы и удалите данные с сервака. Так вы разведете две задачи анализ и OLTP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 10:56 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
>>Назначали ли вы права пользователям на объекты в обеих базах (т.е. дублировали ли пользователей) или работали через хранимые процедуры Пользователи работают через хранимые процедуры. Назначать права не надо, но пользоатель все равно должен существовать в каждой (из 2 или из 12) базе. Права нужны только на процедуру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 11:07 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
To VictorS А можно вопросик? 1. Есть БД A в которой есть storedproc написанная dbo, которая возвращает данные из Table1. У пользователя User1, в БД А есть права на запуск процедуры, но нет прав на таблицу Table1. 2. Создается баз B, в которой создается Table1 с данными за закрытый период, и User1. В storedproc в базе А дописывается что-то вроде: SELECT * FROM A.dbo.Table1 UNION ALL SELECT * FROM B.dbo.Table1 3. Пользователь запускает storedproc из базы A. Но не предоставив прав SELECT на Table1 в базе B, мне кажется вы получите отказ в доступе. Ведь если в базе A процедура будет действовать с правами dbo, то в базе B с правами пользователя, запустившего процедуру из базы А. Может я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 11:25 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
2pkarklin 1. Разве можно указать серверу, чтобы он использовал конкретную filegroup только для одной таблицы ? Расскажите тогда, как это сделать 2. OLAP хранилище и кубы уже проектируется и будут использоваться, но ... архивные данные нужны, если возникнет потребность просмотреть детальную информацию по конкретному клиенту и/или в определенный временной промежуток с точностью до секунды - строить куб с такой детализацией по-моему нелогично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 11:34 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
To Glorry. По поводу filegroup (прямо из BOL). Files and Filegroups Microsoft® SQL Server™ 2000 maps a database using a set of operating-system files. All data and objects in the database, such as tables, stored procedures, triggers, and views, are stored within these operating-system files: Primary This file contains the startup information for the database and is used to store data. Every database has one primary data file. Secondary These files hold all of the data that does not fit in the primary data file. If the primary file can hold all of the data in the database, databases do not need to have secondary data files. Some databases may be large enough to need multiple secondary data files or to use secondary files on separate disk drives to spread data across multiple disks. Transaction Log These files hold the log information used to recover the database. There must be at least one log file for each database. For example, a simple database, sales, can be created with one primary file that contains all data and objects and a log file that contains the transaction log information. Alternatively, a more complex database, orders, can be created with one primary file and five secondary files; the data and objects within the database spread across all six files, and four additional log files contain the transaction log information. Filegroups allow files to be grouped together for administrative and data allocation/placement purposes. For example, three files (Data1.ndf, Data2.ndf, and Data3.ndf) can be created on three disk drives, respectively, and assigned to the filegroup fgroup1. A table can then be created specifically on the filegroup fgroup1. Queries for data from the table will be spread across the three disks, thereby improving performance. The same performance improvement can be accomplished with a single file created on a RAID (redundant array of independent disks) stripe set. Files and filegroups, however, allow you to easily add new files on new disks. Additionally, if your database exceeds the maximum size for a single Microsoft Windows NT® file, you can use secondary data files to allow your database to continue to grow. Placing Tables on Filegroups A table can be created on a specific filegroup rather than the default filegroup. If the filegroup comprises multiple files spread across various physical disks, each with its own disk controller, then queries for data from the table will be spread across the disks, thereby improving performance. The same effect can be accomplished by creating a single file on a RAID (redundant array of independent disks) level 0, 1, or 5 device. If the computer has multiple processors, Microsoft® SQL Server™ 2000 can perform parallel scans of the data. Multiple parallel scans can be executed for a single table if the filegroup of the table contains multiple files. Whenever a table is accessed sequentially, a separate thread is created to read each file in parallel. For example, a full scan of a table created on a filegroup comprising of four files will use four separate threads to read the data in parallel. Therefore, creating more files per filegroup can help increase performance because a separate thread is used to scan each file in parallel. Similarly, when a query joins tables on different filegroups, each table can be read in parallel, thereby improving query performance. Additionally, any text, ntext, or image columns within a table can be created on a filegroup other than the one that contains the base table. Eventually, there is a saturation point when there are too many files and therefore too many parallel threads causing bottlenecks in the disk I/O subsystem. These bottlenecks can be identified by using Windows NT® Performance Monitor to monitor the PhysicalDisk object and Disk Queue Length counter. If the Disk Queue Length counter is greater than three, consider reducing the number of files. For more information, see Monitoring Disk Activity. It is advantageous to get as much data spread across as many physical drives as possible in order to improve throughput through parallel data access using multiple files. To spread data evenly across all disks, first set up hardware-based disk striping, and then use filegroups to spread data across multiple hardware stripe sets if needed. To create a new table on a specific filegroup see CREATE TABLE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 11:48 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
To Glorry (в догонку) >1. Разве можно указать серверу, чтобы он использовал конкретную filegroup только для >одной таблицы ? Расскажите тогда, как это сделать. Прошу извенения. Не понял сразу смысл вопроса. Делается этот так. 1. Создание файла и filegroup: Запускаем EM, открываем свойства БД для которой будем создавать filegroup-сы переключаемся на закладку Data Files. В таблице добавляем новую строчку, заполняя поля File Name, Location и Initial Size. А в поле со списком набираем, например, January. Давим ОК. Теперь у нас в базе появилась filegroup January. 2. Создание таблицы на определенной filegroup: На ветке Tables выбираем New Table. И сразу открываем свойства таблицы. На закладке Tables в поле Table FileGroup выбираем January и нажимаем закрыть. Далее рисуем структуру таблицы и нажимаем сохранить. 3. Создание индексов на той же filegroup: Выбираем Manage Indexes, давим New, заполняем нужные поля, а потом ставим галку File Group и выбираем January. Давим ОК. Повторяем действия для оставшихся 11 месяцев. Теперь у нас каждая таблица и ее индексы лежат в своем файле, каждый из которых можно по отдельности backup и restore, не трогая остальных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 12:25 |
|
||
|
Разделение данных по нескольким базам
|
|||
|---|---|---|---|
|
#18+
Группы - это очень полезный инструмент, но есть тонкости: http://www.sql.ru/articles/mssql/01080302RestoreFileAndFilegroupBackups.shtml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2001, 12:43 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32012527&tid=1825798]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
| others: | 273ms |
| total: | 432ms |

| 0 / 0 |
