Резервное копирование

Dark
Дата: 11.09.2000 06:07:58
Здравствуйте уважаемые.
Очень мучает меня следующий вопрос.
Есть БД SQL 6.5 Каждый день выполняется резевное копировагние БД (на протяжении лет эдак двух) для юзеров интерес представляет информация и изменения в БД лищь за последние две недели.
Причем файл куда все енто валиться естественно постоянно растет.
А вопрос в общем в следующем как сделать так что бы уничтожить всю ненужную информации, а оставить нужную (т.е. за последние две недели)? Конечно интересует как это сделать автоматически, но если такой возможности нет, то буду рад узнать как это делается в ручную.

Заранее премного благолдарен.
Если можно продублируйте ответ мылом на ssz@mail.ru
SergSuper
Дата: 11.09.2000 07:28:05
Можно делать только дамп транзакций, где храняться только изменения, сделанные с предыдущего дампа транзакций. Он намного меньше и делать его можно хоть каждые 5 мин.
Это если я правильно понял проблемму. Потому что подсказать Вам как удалить информацию, которую Вы считаете ненужной несколько затруднительно.
gavrik
Дата: 11.09.2000 08:45:52
Privet,
Osmeljus' dobavit' svoje mnenije, hotja misl' i ne nova...
Schitajetsja, chto "operativnaja" (uchetnaja) baza dannih obichno ne dolzhna soderzhat' zapisej za takoj dlitel'nij period vremeni. Moj sovet - pochistit' bazu dannih s "tekuchkoj", no ne prosto poterev kakije to strochki, a periodicheski peremeschaja ih v druguju Bazu, vozmozhno dazhe v agregirovannih sostojanijah - v vide razlichnih summ i drugogo roda proizvodnih. Pri etom vozrastet i proizvoditel'nost' operativnoj sistemi pri vipolnenii zaprosov i starije cifri budut dostupni.
V nashi dni uzhe suschestvujut koncepcii "OLAP & Data Warehousing" i "OLTP".

S uvzhenijem
Andrey
Vj(from iXBT)
Дата: 15.09.2000 00:29:29
2All: А как сделать так, чтобы соответственно SUBJ выполнялся ежедневно, но не на "обычный" backup device в SQL, а просто в файл вида ИМЯБАЗЫ.ДАТАБЭКАПА. Соответственно файл девайса бэкапа вообще не будет нужен (расти тоже не будет:), а "подчищать" бэкап-каталог можно и вручную, скажем раз в месяц, оставляя только файлы за две недели. Такое точно было на моем сервере (делалось до меня), но после слетания-рестора сервака, восстановилась только сама база, а вот этая хитрая процедурка - нет :( Может кто подскажет?

2Dark: я правильно перефразировал Ваш вопрос? У меня такая же проблема.
AlexandrA
Дата: 15.09.2000 12:52:44
Извени не знаю как в 6.5 но в 7.0 есть параметр процедуры backUp-а FORMAT, который позволяет уничтожить все записи на данном устройстве BackUp-ирования, а вообще создай новое устройство для BackUp-ирования а старое заархивируй и спрячь предварительно его отключив....
для автоматического стирания устаревших данные есть параметр RETAINDAYS (в 7.0, но в 6.5 я думаю тоже есть что-то подобное - поищи в документации). Но перезапись начнется только тогда когда закончится место на дискена котором лежит устройство, так что наверное придется выделить под него какой-нибудь диск.
Привет
Ольга
Дата: 27.09.2000 11:07:40
Dark: не совсем понятно, как у Вас реализовано ежедневное архивирование данных, но обычно это делается с помощью Scheduled Tasks. Как правило, для грамотного архивирования данных в планировщике создаются три задачи: первая создает dump базы с инициализацией устройства (для вашего случая период выполнения этой задачи будет равен двум неделям); вторая задача будет делать dump базы, скажем, каждый день, но!! без инициализации (то есть она не будет удалять предыдущие данные); третья задача будет архивировать только transaction log (например, каждый час). Если интересуют конкретные действия, которые нужно проделать для реализации таких задач в Enterprise Manager для 6.5 или 7.0, спрашивайте.
Vj: это сделать можно. В случае MS SQL 6.5, опять же, делаете задачку, которая будет выполняться через определенный Вами промежуток времени. Задачка будет включать в себя нечто такого вида:
declare @FilePath varchar(255)
select @FilePath='C:\DateBackup\MyDB'+convert(char(6), GetDate(),12)+'.dmp'
DUMP DATABASE MyDB TO DISK=@FilePath WITH INIT
Но, по-моему, такой вариант не очень рационален, поскольку файлы с бэкапами будут накапливаться, а удалять их вручную может оказаться несколько утомительным занятием ;)