database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
ㆍSybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Sybase Q&A 1939 게시물 읽기
No. 1939
DB사이즈 늘려도 문제 없나요?
작성자
초보
작성일
2007-06-07 18:31ⓒ
2007-06-07 18:42ⓜ
조회수
6,688

Can't allocate space for object 'syslogs' in database 'test' because 'logsegment' segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE to increase the size of the segment. 


검색해보니 로그가 풀나서 DB사이즈를 늘리라는 답변이 대부분이던대.. 


DB사이즈를 늘리기전에 한가지 궁금한것이 있습니다.


제가 알기로 서버같은경우(낮은버전) 장치를 한번 늘려놓으면 다시 원상태로 줄일 수 없다고 알고있습니다.


그래서 장치를 늘려잡을땐 항상 신중히 하고 있구요.. 물론 제가 하는건 아닙니다..


고로 사이베이스의 경우도 DB사이즈를 늘려놨을 경우 다시 줄이는것이 가능한지.


딱히 상주하는 DB관리자가 없어서 개발자가 직접 손을 대야되는 상황이라 시스템적인 부분의 변경이 필요할경우 고민이 많이 됩니다..


요약하면 제가 원하는 만큼 사이즈를 늘려잡아도 추후 문제가 되지 않을런지요..



그리고 한가지더 아래 로그를 제가 이해하고 있는게 맞는지.


name                     db_size

----                       -------

test                         1244.0


device_fragments               size          usage                created                   free kbytes     

----------------               ----          -----                -------                   -----------     

master                                2.0 MB data and log         Aug 12 2005  1:03PM                      0

master                               18.0 MB data and log         Oct 24 2006 12:46AM                      0

test                                200.0 MB data and log         Oct 31 2006  2:09PM                      0

test1                              1024.0 MB data and log         Nov 15 2006  9:01PM                     96 


sp_helpdb test 했을경우 위와같이 나옵니다. test가 현제 문제가되는 DB같은대 test1은 무었인가요?

초기 test로 사이즈를 잡고 test1을 추가해서 잡았다는 말인가요? (test + test1 = testDB의 전체 사이즈)

그리고 free kbytes부분에 다른건다 0이고 test1만 96인대.. test1에 96kbytes남았고 나머지는 남은공간이 없다는 말인가요? -_-;;

이 글에 대한 댓글이 총 4건 있습니다.

우선 test db의 총 size는 1224M인데요

master device에 2M,18M
test device에 200M
test1 device에 1024M

이렇게 할당되어 있는거고요


data and log라고 되어 있는거는


data 영역 : table,index,procedure 등이 저장되는 영역

log 영역 : data의 변경내용이 저장되는 영역


이 두가지가 모두 같은 디바이스들에 저장 된다는 겁니다.


log를 없애시려면

dump tran test with truncate_only하시면 됩니다.


나온 메세지가 logsegment가 full이므로 아마도 여유 공간이 생길거라고 봅니다.



해도 안된다면 alter database해주셔야 하고요...




test1만 96인것은 test1 device에만 96K가 사용할수 있는 공간으로 남아있다는 겁니다.





참고로 옵션을 걸어 자동으로 log를 없애줄수도 있고요,


data와 log는 다른 device에 하도록 권장합니다.



또한가지  높은버젼도 줄이는건 안됩니다.

지연님이 2007-06-08 08:58에 작성한 댓글입니다. Edit

1. transaction log를 제거한다.


dump tran test with no_log

go


2. 향후에도 commit시 log를 제거 하려면

use master

go

sp_dboption test, "trunc log on chkpt", true

go

checkpoint

go

수행한다.


3.DB 사이즈가 늘어나지 않았다면 사이즈를 늘린다.

=> logsegment 와 datasegment가 분리되어있지 않아서

    log full 인지 data full이 파악하기 곤란합니다.

    향후 datasegment 와 logsegment를 분리해서 생성해야 될 듯..

영빈~(backfish)님이 2007-06-08 09:00에 작성한 댓글입니다.
이 댓글은 2007-06-08 09:02에 마지막으로 수정되었습니다.

Can't allocate space for object 'syslogs' in database 'test' because 'logsegment' segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE to increase the size of the segment



이렇게 되어 있으니 log full이 맞을것 같네요


data & log라도 data가 full이라면 default segment가 full이라고 나오겠죠~


그리고 no_log는 위험한 옵션인데요~


checkpoint를 기록하지 않고 log를 날리는 겁니다.



고로 어디까지 commit했고 어디까지 rollback을 해야하는지 알수 가 없는 옵션입니다.




물론 대부분의 경우는 잘 되겠지만요.....



자칫 잘못해서 내렸다가 올릴때, 데이타가 엉망이 될수가 있습니다.~

지연님이 2007-06-11 17:19에 작성한 댓글입니다.
이 댓글은 2007-06-11 17:21에 마지막으로 수정되었습니다. Edit

글쿤요..
많은 도움이 됐습니다.
감사합니다.

영빈~(backfish)님이 2007-06-11 22:21에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
1942쿼리 질문?? [1]
방문자
2007-06-11
6485
1941[질문] null 값의 비교... [1]
김재호
2007-06-08
5974
1940쿼리로 가능한지 알고 싶습니다. [3]
왕왕초보
2007-06-08
5746
1939DB사이즈 늘려도 문제 없나요? [4]
초보
2007-06-07
6688
1938systabstats 알려주세요 [4]
Jack
2007-06-04
6185
1937alter table 추가시 위치 제어 [1]
승우
2007-06-04
5310
1936디스크 무결성 점검 작업에 대하여.. [2]
열심도령
2007-06-04
5047
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다