[DB] localHost와 127.0.0.1로 연결 및 차이점

Database/SQL Basic 2013.01.08 15:51

localhost라는 호스트 이름은 일반적으로 IP주소 127.0.0.1의 다른 명친이지만 MYSQL에서는 다소 다른 기본동작을 보인다. 연결할 때 호스트 이름 매개변수로 localhost 를 지정하면, 예상대로 기본적인 TCP/IP 대신 유닉스 소켓을 통해 연결을 시도한다. 그러므로 다음 명령은 유닉스 소켓을 통해 연결할 것이다.


$mysql  --host=localhost


이것은 사람들의 예층대로 작동하지 않으므로 좋지않은 설계이지만 이를 변경하려면 오래된 응용프로그램과 클라이언트 라이브러리와의 호환성이 깨질 수 있으므로 변경하기엔 무리가 있다. 실행되는 장치에 TCP/IP로 연결하는 방법이 두 가지 있다. 호스트 이름 대신 IP 주소를 지정하거나 프로토콜을 명시적으로 지정하는 것이다. 다음 두 명령 모두 TCP/IP를 통해 연결된다.


$ mysql --host=127.0.0.1

$ mysql --host=localhost --protocol=tcp


SSH터널링을 구성할 때 localhost에서 정방향 TCP포트에 연결을 시도하면 작동하지 않는다. 포트로 연결하려면 TCP를 사용해야 하므로, 대신 IP주소 127.0.0.1을 사용해야 한다.


이 호스트의 이름에는 특별한 점이 또 있다. MySQL은 localhost를 %와일드카드에 매치시키지 않는다. 다시말해, user@'%'와 user@localhost에 권한을 지정하는 것은 중복이 아니다.

저작자 표시 비영리 변경 금지
신고

'Database > SQL Basic' 카테고리의 다른 글

[DB] localHost와 127.0.0.1로 연결 및 차이점  (0) 2013.01.08
[DB] DBMS  (0) 2013.01.02
[DB] DBA 역할  (0) 2013.01.02
[DB설계 및 구축] PK 컬럼 순서  (0) 2012.12.28
[기초] 데이터베이스 트랜잭션  (0) 2012.08.30
[기초] 구조적 질의 언어(SQL)  (0) 2012.08.30

[DB] DBMS

Database/SQL Basic 2013.01.02 17:35

1. DBMS 란 ?

  • 데이타베이스는 여러 부서가 공통적으로 활용 할 수 있도록 데이타를
    통합하여 저장하는 것으로써 데이타베이스를 사용하는 사용자는 여러명이며 사용 목적 또한 각 사용자에 따라 다양해 진다.
  • 데이타를 통합함에 따라 동일한 데이타는 한번만 저장하여 공유하므로 데이타의 중복성은 근본적으로 해결될 수 있다.
  • DBMS는 데이타베이스에 대한 사용자의 모든 요구를 수행할 수 있는 기능을 갖기 위해 여러가지 구조를 갖추고 다양한 기능을 제공하며 이들 구조와 구조 사이의 연결 및 이를 이용하는 데이타베이스 언어로 구성된 일종의 소프트웨어 시스템이다.
  • 사용자의 요구를 수용할 수 있는 기능이란 데이타베이스를 생성, 정의, 유지하는 기능과 사용자가 원하는 모든 정보를 조작할 수 있는 기능 및 항상 최적상태를 유지하기 위하여 취할 수 있는 어러가지 제어 기능을 말합니다. DBMS를 사용하면 아래와 같은 장점들이 있다.


  • 데이타의 중복의 최소화
    데이타를 통합하여 이용할 수 있게 구성함으로써 이러한 중복을 사전에
    배제할 수 있다.

  • 데이타의 공통 사용
    같은 내용의 데이타를 한번만 저장하고도 여러가지 형태로 표현해 줄 수 있는
    DBMS의 정교하고도 다양한 기능 때문에 데이타의 공유가 가능하다.

  • 데이타의 일관성 유지
    데이타의 중복저장을 피함으로써 동일한 내용을 서로 다른 장소에 저장함에
    따라 나타날 수 있는 데이타간의 불일치나 모순성을 해결할 수 있다.

  • 데이타의 무결성 유지
    DBMS는 입력이나 갱신작업을 수행할 때 마다 사용된 데이타가 무결성 보장
    규칙에 위배되지 않는 정확한 값인가를 검사하여 유효한 데이타만 허용하게
    되므로 무결성을 유지할 수 있다.

  • 데이타의 보안을 보완

  • 표준화가 가능
    중앙에서 데이타를 통제함으로써 정보, 문서형식등을 총괄하여 표준화를
    기할 수 있다.
  • 요구사항을 쉽게 파악 데이타를 수집 분석하여 요구사항을 파악하기가 쉬우므로 조직전체에 가장 유익한 구조로 조작될 수 있도록 하여 최대의 효과를 얻을 수 있다.
  • DBMS는 데이타등을 통합 저장하여 데이타베이스를 구축하고 DBMS를 통하여 사용자와 데이타간을 중앙 집중으로 통제함으로써 파일 시스템에서 야기되는 여러 문제들을 해결하고 위와 같은 장점들을 얻을 수 있다.
  • 이러한 이유들로 인하여 현실 세계에서 요구하는 정보의 정확성, 신속성의 요구를 충족시킴으로써 자연적으로 데이타베이스는 전산 시스템의 필수적인 요소로 자리잡고 계속 발전하게 되었습니다. 데이타베이스를 중앙 집중식으로 관리함으로써 간단 하면서 쉽게 데이타의 보안을 유지 할 수 있다.
2. DBMS의 발전 과정

  • DBMS의 발전역사는 일반적으로 10년 단위로 그 상용화의 성과를 살펴볼 수 있다. 데이타 관리의 초기 단계인 파일 시스템으로 구조로 부터 사용자의 업무가 복잡, 다양해져서 DBMS의 필요성을 느낌에 따라 1960년대에 최초로 계층형(Heirachical) DBMS가 개발되어 상용화에 성공하게 되었다.
  • 1970년대에 들어오면서 기존의 계층형 DBMS에서 약간의 데이타 접근방식을 보완한 망형(Network) DBMS가 개발되어 사용되어져 왔다.
  • 이러한 DBMS들은 1980년대에 들어오면서 새로운 계기를 맞게 되었는데 기존의 DBMS와는 그 구조와 발상이 전혀 새롭고 미래의 DBMS로 각광을 받을 수 있는 관계형(Relational) DBMS가 출시하게 되었다.
  • 관계형 DBMS의 이론은 1970년대 이전 부터 나오기 사작하였지만 그 이론이 제품화되어 최초로 상용 DBMS로 판매되게 된것은 1979년 ORACLE 사에 의해서이다.
  • 처음 관계형 DBMS가 출시 되었을 때에는 생산성은 매우 뛰어 났으나 하드웨어의 자원을 너무 많이 차지하고 수행속도가 매우 느린 단점이 있었습니다. 그러나 지속적인 하드웨어의 발전및 DBMS 공급사의 과감한 연구/개발 투자로 인해 관계형 DBMS는 1980년대 중반에 들어오면서 거의 모든 업무에 뛰어난 생산성 향상과 함께 만족할만한 수행속도를 가져올 수 있게 되자 새로운 전산기술 개발에 대한 사용자들의 기대와 욕구를 충족하게 되었다.
  • 1990년대에는 멀티미디어에 대한 요구에 부응하기 위해 객체지향형 DBMS가 발표되어 일부 회사에서 제품을 발표하고 있으나 실용화 단계까지는 시간이 필요하다고 판단됩니다. 그러면 현재까지 발표된 각 DBMS의 구조 및 특징들을 살펴보겠다.
3. 관계형(Relational) DBMS

  • 1970년대 초반에 IBM 연구소의 'System R'이라는 프로젝트가 진행되었으며, 여기서 언어의 어떤 기능을 배우는 것이 어려운지를 파악하기 위한 연구가 수행 되었고, SQL 언어에서 그런것들이 제거 되었으며 또한 자료의 정의, 자료 처리와 자료 접근 관리의 완전한 기능을 가지는 언어로 확장되었다.
  • 데이타언어의 개정된 명세가 1976년 11월에 IBM의 "Journal of Research and Development"지에 논문으로 발표 되었고 1976년에 나온 이 논문이 ORACLE의 탄생의 초석이 되었습니다. 1977년에 ORACLE사의 설립자는 SQL 언어를 사용하여 관계형 DBMS를 구성 하기로 하였으며, 그 결과 ORACLE은 1979년에 최초의 상용화된 관계형 DBMS를 시판 하게 되었다.
  • 1982년에 IBM은 DOS/VSE와 VM에서 운영되는 SQL/DS를 내 놓았으며, 1984년에 IBM은 대형을 위해 MVS 운영체제하에서 수행되는 DB2를 발표하였습니다. 또한, SQL은 오늘날 ANSI 위원회에 의해 관계형 DBMS의 표준언어로 받아 들여졌다.
  • 이와같은 탄생역사를 가진 관계형 DBMS는 1979년초 최초의 상용화된 ORACLE DBMS를 시작으로 하여 현재까지 PC를 비롯한 IBM의 대형급 까지 매우 다양한 기종에서 운용되고 있으며 현재는 그야말로 관계형 DBMS의 전성기를 이루고 있다. 대표적인 상품으로는 ORACLE사의 ORACLE7을 비롯하여 Sybase, Informix, IBM DB2, IBM SQL/DS, ASK사의 Ingres, VMS/Rdb등이 있다.
4. 구조 및 특징

    1. 관계형 DBMS는 기존의 계층형 또는 망형의 DBMS가 레코드들을 연결하는 방식과는 달리 이차원의 테이블 즉, 컬럼과 로우로써 이루어진 개념이다.

    2. 컬럼은 정보의 종류를 표시하고 로우는 각 항목에 표시된 값들의 집합체이다.

    3. 관계형 모델은 데이타의 구조적인 표현이 단지 컬럼과 로우로써 이루어졌고, 그럼으로써 데이타의 접근이 매우 편리하다.

    4. 또한 데이타의 실제 저장 장소의 구조가 바뀌더라도 응용프로그램을 변경시킬 필요가 없는 물리적 구조로 부터의 독립성을 제공함에 따라 프로그램의 수정이 어려워서 데이타의 구조변경을 쉽게 하지 못하던 어려움이 없어졌다.

    5. 따라서 관계형 DBMS (RDBMS)는 데이타의 저장및 갱신을 쉽게 할 수 있으며 데이타베이스의 재구축시 기존의 어느 DBMS보다도 쉽게 유지보수가 가능하다.

단 점

1. 사용상의 편리함이나 뛰어난 점이나 유지 보수가 쉬운 반면 수행속도가 느리다고 하는 것이 RDBMS의 제일 큰 단점이다.

2. 그러나 이러한 단점은 RDBMS 공급업체의 꾸준한 연구개발과 지속적인 성능개선 노력에 힘입어 현재는 계층형 DBMS가 낼수 있는 1000 TPS 이상의 성능을 발휘하고 있다.

저작자 표시 비영리 변경 금지
신고

'Database > SQL Basic' 카테고리의 다른 글

[DB] localHost와 127.0.0.1로 연결 및 차이점  (0) 2013.01.08
[DB] DBMS  (0) 2013.01.02
[DB] DBA 역할  (0) 2013.01.02
[DB설계 및 구축] PK 컬럼 순서  (0) 2012.12.28
[기초] 데이터베이스 트랜잭션  (0) 2012.08.30
[기초] 구조적 질의 언어(SQL)  (0) 2012.08.30

[DB] DBA 역할

Database/SQL Basic 2013.01.02 17:12
  • 설치와 환경설정
    - 소프트웨어 설치
    - 환경 설정
  • 보안 관리
  • 운영
    - 백업과 복원
    - 사용자 관리
    - 기타 일상적인 운영 업무
  • 서비스 레벨 유지
    - 성능 최적화 및 성능 모니터링
    - 용량 계획 (Capacity Planning)
  • 시스템 가동 시간 관리
    - 시스템 정지 시간의 계획과 일정 관리
  • 문서화 작업
  • 작업 절차 계획 및 규격화
    - 운영 유지보수 계획 수립
    - 재난 복구 계획 수립
  • 설계 및 개발 지원
    - 데이터 모델링
    - 데이터베이스 설계
    - 저장 프로시저 개발
    - 응용 프로그램 개발
  • 개발 환경 관리
    - 개발 시스템 환경 별도 제공 및 개발 시스템 관리
  • 긴급 상황 해결/장애 복구
  • SQL Server 관리에 필요한 지식 숙지

DBA 작업의 기본적인 원칙

DBA가 시스템 유지를 위하여 일반적으로 수행하는 모든 작업들에 대하여 기본적으로 다음과 같은 원칙에 의거하여 작업할 것을 권고합니다.

  • 작업 표준화 체계 수립

    표준화는 관리에 있어서 매우 중요한 요소입니다. 자신의 시스템에 가장 적합한 표준화 체계를 수립하고, 전체 시스템에 대하여 표준화된 관리 체계를 적용하여 관리해야 합니다. 예를 들어, 다중의 DB 서버를 관리하는 경우에는 표준화가 특히 중요합니다.

  • 문서화

    DB 관리와 같이 중요한 작업은 사람의 기억에 의한 주먹구구식의 작업이 되어서는 안됩니다. 어떤 경우라도 항상 정확하고 일관된 작업이 가능하도록 문서화가 필요합니다. 기록 가능한 모든 작업들에 대해서 문서화하고, 변경이 발생하면 지속적으로 업데이트하는 관리가 필요합니다.

    • 작업 매뉴얼 : 작업 수행 절차에 대한 정보 (설치, 장애 복구, 백업과 복원 전략, 주기적으로 수행하는 작업 등에 대한 작업 절차 및 참고 사항이 이에 포함될 수 있으며, 일반적이고 중요한 정보는 운영 매뉴얼에 기록하여 모든 DBA가 참조할 수 있도록 합니다.)
    • 시스템 환경에 대한 정보 : 서버의 하드웨어, 소프트웨어, 네트워크 등에 대한 정보
    • 담당자 및 관계자에 대한 정보 : 시스템과 관련된 내/외부 조직에 포함되는 모든 사람과 하드웨어/소프트웨어 제품 및 서비스 공급업체 및 담당자에 대한 정보
    • 장애 기록 일지 : 발생된 문제와 문제 해결에 관한 모든 절차에 대한 기록 (장애 기록에 대한 내용은 활용 및 검색이 용이하도록 웹 기반으로 만들어, 유사한 문제의 재발 시에 신속하게 처리할 수 있도록 합니다.)
  • 스크립트화

    반복적, 주기적으로 수행하는 모든 작업들은 엔터프라이즈 관리자를 사용하는 대신, 스크립트를 작성하여 수행하는 것을 원칙으로 합니다. 스크립트를 사용하면 오류 발생 가능성을 최소화할 수 있으며 반복적인 작업을 효율적으로 수행할 수 있습니다. 스크립트는 보안을 위하여 안전한 디렉터리에 중앙 집중적으로 관리하는 것이 바람직하며, 스크립트 작성 시에는 응용 프로그램과 마찬가지로 주석을 기술하여 쉽게 이해하고 활용할 수 있도록 합니다. 만약 주석만으로 불충분한 경우에는 문서를 작성하여 관리합니다.

  • 자동화

    주기적으로 수행해야 하는 작업들은 가능한 한 자동화하여 DBA의 업무 효율성을 제고할 것을 권고합니다. 예를 들어 DB 서버 성능 데이터의 수집, 디스크 공간의 확인, 백업, 블로킹 감지, 데이터 타입 오버플로우 감지 등의 작업들은 자동화가 가능합니다. 단순히 수행을 자동화하는 차원을 넘어서, SQL Server에서 제공하는 다양한 기능들을 활용하면 자동으로 경고 메일의 발송, 문자 메시지의 발신, 문제 해결을 위한 작업의 수행 등이 가능하기 때문에, DBA가 지속적으로 시스템을 모니터링하지 않더라도 시스템에 발생한 문제를 조기에 감지하는 것이 가능합니다. DBA가 주기적으로 수행되는 작업에 할애하는 시간은 가능한 한 최소화하고, 주기적인 관리 작업을 통하여 확보한 지식을 기반으로 응용 프로그램과 서버의 성능을 향상시키기 위한 전략을 모색하는데 많은 시간을 할애하는 것이 바람직합니다.

  • 신중한 변경 관리 및 롤백 전략 수립

    운영중인 시스템에 어떤 변경작업을 수행하는 경우에는 가능한 한 충분한 사전 테스트를 거친 후에 작업해야 하며, 롤백 전략을 수립한 다음에 작업하는 것을 원칙으로 합니다. 또한 한번에 여러 가지 변경 작업을 수행하지 말고, 하나의 변경 작업을 수행하고 그 변경 작업이 미친 영향을 관찰하는 것이 바람직합니다.
    모든 변경 작업에 대해서 롤백 전략을 수립하는 것이 원칙이며, 롤백에 필요한 사항들을 문서로 기록하고 롤백에 필요한 스크립트 등을 작성하고 테스트하여 검증합니다. 특히 대용량 데이터베이스의 경우에는 문제 발생 시 복구에 소요되는 시간이 길기 때문에 충분한 사전 테스트와 롤백 전략 수립이 매우 중요합니다.


    DBA가 주기적으로 수행해야 하는 작업

    시스템에 따라 차이가 있을 수 있지만, DBA는 시스템 유지를 위하여 일반적으로 수행해야 하는 작업들에 대하여 이해하고 있어야 하며, 다음과 같은 작업들을 주기적으로 수행해야 합니다.

  • 일 단위로 수행해야 하는 작업

    • 시작되어야 할 서비스들이 제대로 시작되어 있는지 확인합니다.
    • Windows NT 또는 Windows 2000의 이벤트 뷰어를 사용하여 오류 발생 여부를 점검합니다.
    • SQL Server 오류 로그에 오류 메시지가 기록되어 있는지 점검합니다. 자세한 내용은 [SQL Server 오류 로그 보기]를 참조하십시오.
    • 데이터베이스 파일과 로그 파일의 확장에 대비하여 디스크에 충분한 여유 공간이 있는지 확인합니다.
    • 데이터베이스 파일과 로그 파일의 크기와 실제로 사용되는 공간을 모니터링하며, 공간 부족으로 자동 확장이 예상되는 경우에는 미리 파일을 확장하여 충분한 공간을 확보합니다.
    • SQL Server 작업(Job)의 성공/실패 여부를 점검합니다.
    • 매일 데이터베이스 전체 백업 또는 차등 백업을 수행하기로 되어 있는 경우라면, 데이터베이스 전체 백업을 수행합니다. 자동화되어 있는 경우에는 백업이 성공적으로 수행되었는지 점검합니다. 데이터베이스 전체/차등 백업 주기는 시스템 여건과 복원 전략에 따라 달라집니다.
    • SQL Server 트랜잭션 로그를 백업 받습니다. 자동화되어 있는 경우에는 백업이 성공적으로 수행되었는지 점검합니다. 백업 주기는 시스템 여건에 따라 백업 주기는 분 단위, 시간 단위, 일 단위로 달라질 수 있으며, 트랜잭션 백업 주기에 따라 트랜잭션 로그 파일의 크기가 달라집니다. 참고로 복원이 불필요한 테스트 DB에 대해서는 복구 모델을 단순으로 설정하면 트랜잭션 로그에 대한 주기적인 관리를 줄일 수 있습니다.
    • Master, model, msdb, 배포(distribution) 데이터베이스도 변경 사항이 있으면 주기적으로 백업해야 합니다. 시스템 카탈로그의 변경이 이루어진 후에는 master 데이터베이스의 전체 백업을 수행합니다. 경고, 작업(Job), 운영자, 로그 전달(log-shipping), 복제, DTS 패키지 등에 변경이 발생한 다음에는 msdb를 백업해야 합니다. Model 데이터베이스에 변경작업을 수행한 다음에는 model을 백업해야 합니다.
    • 시스템 모니터를 사용하여 성능 카운터를 모니터링함으로써, 적절한 성능이 유지되고 있는지 점검합니다. 최소한 시스템 모니터에서 프로세서, 메모리, 디스크(I/O), 네트워크에 대한 카운터들은 필수로 점검해야 합니다. 문제 발생 시 또는 추가적인 분석이 필요한 경우에는 관련 성능 카운터들을 추가로 분석합니다.
    • 복구 모델이 전체 복구가 아니라면, 최소 로깅 작업(Minimal-logged operation)을 수행한 다음에는 차등 백업을 수행합니다.
    • 블로킹, 교착상태(Deadlock)의 발생 여부를 점검합니다.
    • 오래 수행되는 쿼리 또는 리소스를 과다하게 사용하는 쿼리가 있는지 점검합니다.
    • 문제가 발생하면 문제 해결을 위한 활동을 수행하며, 문제 분석 및 해결 과정에 대한 내용을 가능한 한 상세하게 문서화합니다.
    • 통계 자동 갱신(Auto update statistics) 옵션이 비활성화되어 있는 데이터베이스의 테이블들에 대해서는 주기적으로 (예:매일, 매주) UPDATE STATISTICS 작업을 수행합니다.
  • 주간 단위로 수행해야 하는 작업

    • 모든 시스템 데이터베이스와 운영중인 사용자 데이터베이스에 대한 전체/차등 데이터베이스 백업을 수행합니다.
    • 통계 자동 갱신(Auto update statistics) 옵션이 비활성화되어 있는 데이터베이스의 테이블들에 대해서 UPDATE STATISTICS를 매일 또는 매주 수행합니다.
    • 인덱스의 조각화를 제거합니다. CREATE INDEX WITH DROP_EXISTING 또는 DBCC DBREINDEX를 수행하여 인덱스를 재구성함으로써 물리적, 논리적 조각화를 제거할 수 있으며, DBCC INDEXDEFRAG를 사용하면 논리적인 조각화를 제거할 수 있습니다. 자세한 내용은 온라인 설명서를 참조하십시오.
    • 대형 일괄 처리의 작업 등으로 인하여 로그 파일이 과다하게 확장된 경우에는 로그 파일의 사용되지 않는 여분의 공간을 제거합니다.
  • 월간 단위로 수행해야 하는 작업

    • 전체 운영 체제를 백업합니다.
    • 최소 월 1회 모든 시스템 데이터베이스와 운영 데이터베이스에 대하여 전체 백업을 수행해야 합니다.
    • DBCC CHECKDB를 수행하여 데이터베이스의 무결성을 점검합니다. DBCC CHECKDB를 수행하면 서비스나 다른 작업에 영향을 미칠 수 있으므로, 테스트 장비에 모든 시스템 데이터베이스와 운영 데이터베이스를 복원하고, 복원된 모든 시스템 데이터베이스와 운영 데이터베이스를 대상으로 DBCC CHECKDB를 수행하여 무결성을 점검하는 것이 바람직합니다.
    • Sqldiag.exe를 수행하고 결과를 저장합니다.
    • 성능 데이터를 수집하여 시스템이 충족시켜야 하는 기준과 비교하여, 성능 향상 및 향후의 용량 계획에 활용합니다.

  • 저작자 표시 비영리 변경 금지
    신고

    'Database > SQL Basic' 카테고리의 다른 글

    [DB] localHost와 127.0.0.1로 연결 및 차이점  (0) 2013.01.08
    [DB] DBMS  (0) 2013.01.02
    [DB] DBA 역할  (0) 2013.01.02
    [DB설계 및 구축] PK 컬럼 순서  (0) 2012.12.28
    [기초] 데이터베이스 트랜잭션  (0) 2012.08.30
    [기초] 구조적 질의 언어(SQL)  (0) 2012.08.30


    티스토리 툴바