Помогите стартонуть базу.!!!!!!!!!!!
Таблица содержит более 5 000 000 строк, 26 колонок. Размер таблицы измеряется в сотнях Мбайт (а может и больше - не мерял). Попытался её очистить одной командой delete (!!!!), потом уже понял глупость, эту транзакцию следовало бы раздробить и удалять поэтапно строки типа

SET ROWCOUNT 10000
WHILE EXISTS ( SELECT 1 FROM <myTable> )
BEGIN
DELETE FROM <myTable>
END
SET ROWCOUNT 0

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

Не дождавшись завершение удаления (6 час уже колбасило), я оборвал сессию и перезагрузил сервер.
Сервер останавливается на (вистит так уже сутки) ..

Recovering database 'dbmain'.
Recovery dbid 5 ckpt (8728982,14) oldest tran=(8946991,23)

Очистка логсегмена не помогает (да он чистый как показывает sp_helpdb dbmain)

ЧТО ДЕЛАТЬ?

SQL Server/11.0.3.3/P/Linux Intel/Linux 2.0.36 i586

1> select * from sysdatabases
2> go
name dbid suid status version logptr
crdate dumptrdate status2
audflags deftabaud defvwaud defpraud
------------------------------ ------ ------ ------ ------- -----------
-------------------------- -------------------------- -------
----------- ----------- ----------- -----------
dbmain 5 1 -32768 1 8946991
Mar 17 2005 8:26PM Dec 8 2005 2:23AM -32719
0 0 0 0
manager 6 1 64 1 14837
Mar 17 2005 8:43PM Dec 6 2005 7:30AM -32720
0 0 0 0
master 1 1 0 1 2075
Jan 1 1900 12:00AM Dec 7 2005 12:26PM -32768
NULL NULL NULL NULL
model 3 1 0 1 431
Jan 1 1900 12:00AM Mar 17 2005 8:21PM -32768
NULL NULL NULL NULL
sybsystemprocs 4 1 8 1 7590
Mar 17 2005 8:20PM Dec 8 2005 8:41AM -32768
0 0 0 0
tempdb 2 1 4 1 467
Dec 8 2005 9:37AM Dec 8 2005 10:41AM -32768
NULL NULL NULL NULL


1> sp_helpdb dbmain
2> go
name db_size owner dbid
created
status
------------------------ ------------- ------------------------ ------
--------------
------------------------------------------------------------------------------------------------------
dbmain 17600.0 MB sa 5
Mar 17, 2005
abort tran on log full, offline

device_fragments size usage free kbytes
------------------------------ ------------- -------------------- -----------
dbmain 80.0 MB data and log 0
dbmain 20.0 MB log only 20480
dbmain01 2000.0 MB data only 1952
dbmain02 2000.0 MB data only 6992
dbmain03 2000.0 MB data only 1387520
dbmain04 2000.0 MB data only 2048000
dbmain05 2000.0 MB data only 2048000
dbmain06 2000.0 MB data only 2048000
dbmain07 2000.0 MB data only 2048000
dbmain08 2000.0 MB data only 2048000
dbmainlog01 200.0 MB log only 204800
dbmainlog02 300.0 MB log only 307200
dbmainlog02_ 1000.0 MB log only 1021024


Дело вообще то обстояло так:
зашёл isql, запустил :
use dbmain
go
delete from cdr whre datepart(month,strat_time)=11
на 6-ом часе выполнения команды моя ssh сессия оборвалась, захожу на сервер повторно, вижу моя сессия весит старая, жду ещё пару часов, жду пока лог сегмент (периодически проверяю sp_helpdb dbmain) не остановится уменьшатся. В определённый он перестал изменятся (при этом все лог сегменты были по нулям и только dbmainlog02_ = 48234).
делаю
dump tran dbmain with no_log
go
Место на лог сегментах какбы освободилось, далее:
select count(*) from cdr where datepart(month,start_time)=11
- висит. ничего не отвечает.
Ну я и перезапускаю сервер.. он не стартует.

Peter Kirillow - это врятли поможет. Дело не в лог сегменте. Он свободен. Пока жду до завтра , может подымится (а она обязательно подымится - только вопрос когда? сервер тем временем стоит и начальство в панике и удивляется моему спокойствию)
Дампа именно нужной таблицы нет, сама база востанавливается из sql кода и ежедневного дампа таблиц (bcp),за исключением таблицы cdr :(
Какие ещё предложения?
Какие ещё предложения?

Лог:

Но проблема уже решилась вчера в полночь. Один из админов вобщем несмотря на мои запреты всё же перегрузили сервак пока база колбасила своё Recovery. И чтож я вижу к удивлению в логах :

*** Bypassing recovery of database id 5

И база при этом поднялась, селекты мои принимает - но при коннекте к ней программ выдавала им чтото вроди - Database is in BYPASS RECOVERY mode.
Я захожу в dbmain,
dump tran dbmain with no_log
- при этом где то минуту сервак шуршал диском, потом перегружаю


База работает!
Всем спасиба! (хотя я так и не понял причину этого *** Bypassing recovery of database id 5 - есть идёи?)

авториз-за status=-32768
спасиба. запомню.

Дампы ... :) база 17 гиг занимает. её дамп - 2-3 гига и делается долго(около часа).
а упакованная структура базы - 5 метров (постоянный). +данных зампы таблиц bcp гдето 600 меторов (делается за 20-30 минут)(без таблицы CDR - эту не дампим, там другая технология - данные за каждый день ложатся в файлы в удобном для отчётов виде, назад то можно загнать, но не предусмотрено. В базе есть промежуточные отчёты по ней. )

авторЖдать. Или восстанавливаться из хорошего дампа.
Если ты скипнешь recovery, у тебя в базе будет черти что

Я не ждал, а всёже сбросил recovery. Дело в том что базу я приостановил после моего delete. И скинуть recovery в моём случае - значит отменить удаление. В режиме BYPASS RECOVERY после команды "dump tran dbmain with no_log " и последующей перезагрузки - база стартонула нормально и не стала рековерить.

sybdba;) складывается ощущение, что база используется постольку-поскольку, а файлы рулят немеряно ;)
- а как иначе? если за две недели набирается пару миллионов записей (при 20 с лишним столбцов в таблице) с ними работать почти не возможно на данной версии Sybase( апргрейд в моём случае невозможет - не моя разработка базы и приложений)

sybdbaможно попробовать поиграться с памятью отводимой бекап-серверу - в целях ускорения снятия дампа...
- я выделяю shared memory при старте Sybase -
echo 805306368 > /proc/sys/kernel/shmmax
- база в настройках имеет строку при этом (1 еденица = 2 Kb):
[Physical Memory]
total memory = 358400 (716800 Mb)
Для backup сервера не тратил память (всего памяти 1 Gb на сервере стоит)

sybdbaкстати, при вашем подходе вы получаете замедление работы в начале работы с базой.
А индексы у вас сколько строятся после утренней заливки?
- нет, не наблюдается особого замедления. Не совсем понятно что такое утренняя заливка. Но когдато заливал данные в базу из bcp файлов (при этом скрипт сначало удаляет индексы заливает таблицу а потом создаёт) - время на это около 5-10 минут уходит (опять таки - не берём таблицу CDR).

Вот сейчас запускаю поэтапное удаление записей........

Бэкап в bcp файлы делаются каждую ночь (за исклюением таблицы cdr). Таблциа CDR - каждую ночь скрипт вылаживает суточные данные в отдельные файлы. Всё остально (отчёты, настройки, экаунты клиентов, балансы, проводки) хранится и крутится в базе. Файлы CDR не бекапятся через bcp утилиту из-за размера большого и не обрабатываются в базе (за исключением процедуры генерирования отётов - каждый день снимаются промежуточные отчёты). Далее - если ктото раберает полёт какого-то звонка, счёта полугодиной давности например - лезет а этот текстовые файлы (есть ряд скриптов-утилит на bash которые работают с файлами и обрабатывают намного быстрее чем если бы это была база - селект данных за месяц может длится пару часов и при этом база тормозит). Заливка обратно в базу делается очень редко (разве что винт летит или перенос данных идёт либо какая то таблица слетела)

Индексы есть - но что значит их перестраивать - разве это не делатся автоматически ?

Выливка таблиц каждые сутки , заливка поти никогда (только в случае восстановления)
Но щас другая фигня. Запустил я


После 5 минут гдето выдаёт мне:


Кто то может разшифровать ? что опять не так?

Ошибочка
dump tran with no_log

ВОбщем я понял что таблица cdr мне не простила токо что я ей сделал...
вобщем сделал так

1. Создал новую таблицу cdr2, копию cdr
2. insert into cdr2 select * from cdr where datepart(month,start_time)>11
(при этом скопировалось 1770 строк вместо ожидаемых 600 000)
3. exec sp_rename cdr, cdr_old
4. exec sp_rename cdr2, cdr
5. Создал индексы на таблице CDR (обновлённая которая)

Теперь столкнулся с такой проблемой - таблица моя старая cdr_old при попытке с ней чтото сделать (строки посчитать или dbcc checkallock (cdr_old)) отбрасывает с ошибкой и при этом сервер ложится....
Наверное отмена рекавери не есть хорошо

Vlad_5181 Бэкап 24Гб занимает около 40 минут на 11,9,2,6, Xeon1800, RAID5 на другой сервер в сети. Настройки бэкап-сервера по умолчанию. Все работает автоматом ночью
Да. Тоже вариант. Но тут в данной системе такие схемы разработаны:
Вариант 1 - делается зеркалирование базы данных на другой локальный диск (средствами самой Sybase).
Вариант 2 - написан модуль репликации(он работает всегда).Представляет собой интерфейс между приложениями и базой. В режиме репликации он по udp порту шлёт данные (SQL интрукции) другому серверу, а каждую ночь идёт dump bcp с текущего сервера и load bcp на другой (второй - прописан в интерфейсном файле на главном сервере, данные льются по 2000 порту(порту базы)). Второй сервер представляет собой копию работающего и может принять нагрузку в любой момент

Но вопросов у меня не меньше сейчас.
Перед махинациями с таблицей CDR, команда "sp_depends cdr" выдавала перечень процедур которые работают с данной таблицей. После
3. exec sp_rename cdr, cdr_old
4. exec sp_rename cdr2, cdr
Запускаем"sp_depends cdr"
выдаёт:Object doesn't reference any object and no objects reference it.
По мануалу sp_rename -только меняет имя объекта. Просмотрел процедуры - в них по прежнему cdr фигурирует, но физически работа идёт с таблицей cdr_old!!!!!! моя новай cdr таблица без измененния стоит второй день!!!
Зато теперь "sp_depends cdr_old" выдаёт все те процедуры.
Вобщем бред какойто!!!
Теперь задампил таблицу cdr_old (1141434 rows copied.), Хочу дропнуть обе таблицы и создать cdr, залить данные с дампа и создать индексы - что скажете господа? сработет?