'SQL Server 2014'에 해당되는 글 20건

  1. Hekaton native 저장 프로시져 실행 계획 보기는 어떻게?
  2. Hekaton Sample DB 생성하기~~
  3. Architecture of the Hekaton compiler. - 공부중...
  4. [SQL2014] Features - Buffer Pool Extension
  5. Hekaton: SQL Server’s Memory-Optimized OLTP Engine
  6. Microsoft® SQL Server® 2014 CTP1 Product Guide
  7. SQL Server 2014 - Hekaton
  8. SQL2014 평가판 알람받기 등록
  9. [펌] SQL2014 공개 자료
  10. SQL Server 2014 In-Memory OLTP (“Hekaton”) Whitepaper

정말 궁굼했다^ 벤자민 아저씨가 트위터에서 알려주셨어요. 

Starting with CTP2, we will be supporting SHOWPLAN_XML (also called the “estimated execution plan” in Management Studio), so you will be able to see the plan that was used to compile the procedure.”


http://msdn.microsoft.com/en-us/library/dn296374(v=sql.120).aspx 링크에 db 생성부터 데이타까지 모두 들어가 있음 실행만 하면 됨

2014.08.07 샘플 데이타베이스 추가됨..
https://msftdbprodsamples.codeplex.com/releases/view/125550

원본 문서 :
http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf
http://sites.computer.org/debull/A13june/Hekaton1.pdf

   

   

5. PROGRAMMABILITY AND QUERY PROCESSING

Hekaton maximizes run time performance by converting SQL statements and stored procedures into highly customized native code. Database systems traditionally use interpreter based execution mechanisms that perform many run time checks during the execution of even simple statements. Our primary goal is to support efficient execution of compile-onceand-execute-many-times workloads as opposed to optimizing the  execution of ad hoc queries. We also aim for a high level of language compatibility to ease the migration of existing SQL Server applications to Hekaton tables and compiled stored procedures.

Consequently, we chose to leverage and reuse technology wherever suitable. We reuse much of the SQL Server T-SQL compilation stack including the metadata, parser, name resolution, type derivation, and query optimizer. This tight integration helps achieve syntactic and semantic equivalence with the existing SQL Server TSQL language. The output of the Hekaton compiler is C code and  we leverage Microsoft's Visual C/C++ compiler to convert the C code into machine code. While it was not a goal to optimize ad hoc queries, we do want to preserve the ad hoc feel of the SQL language. Thus, a table and stored procedure is available for use immediately after it has been created. To create a Hekaton table or a compiled stored procedure, the user merely needs to add some additional syntax to the CREATE TABLE or CREATE PROCEDURE statement. Code generation is completely transparent to the user   

As noted above, we begin by reusing the existing SQL Server compilation stack. We convert the output of this process into a data structure called the mixed abstract tree or MAT. This data structure is a rich abstract syntax tree capable of representing metadata, imperative logic, expressions, and query plans. We then transform the MAT into a second data structure called the pure imperative tree or PIT. The PIT is a much "simpler" data structure that can be easily converted to C code (or theoretically directly into the intermediate representation for a compiler backend such as Phoenix [17] or LLVM [11]). We discuss the details of the MAT to PIT transformation further in Section 5.2. Once we have C code, we invoke the Visual C/C++ compiler and linker to produce a DLL. At this point it is just a matter of using the OS loader to bring the newly generated code into the SQL Server address space where it can be executed.

   

5.2 Compiled Stored Procedures

There are numerous challenging problems that we had to address to translate T-SQL stored procedures into C code. Perhaps the most obvious challenge is the transformation of query plans into C code and we will discuss our approach to this problem momentarily. There are, however, many other noteworthy complications. For example, the T-SQL and C type systems and expression semantics are very different. T-SQL includes many data types such as date/time types and fixed precision numeric types that have no corresponding C data types. In addition, T-SQL supports NULLs while C does not. Finally, T-SQL raises errors for arithmetic expression evaluation failures such as overflow and division by zero while C either silently returns a wrong result or throws an OS exception that must be translated into an appropriate T-SQL error.

   

   

   

관련 링크 : http://msdn.microsoft.com/en-us/library/dn133176(v=sql.120).aspx

   

Buffer Pool Extension 확장 기능의 이점

  • Increased random I/O throughput
  • Reduced I/O latency
  • Increased transaction throughput
  • Improved read performance with a larger hybrid buffer pool
  • A caching architecture that can take advantage of present and future low-cost memory drives

       

SSD 정보는 여기 참고

   

Buffer Pool Extension 구성

   

   

Buffer Pool Extension Size는 물리 최대 메모리 1:16배 또는 작게 정도를 추천한다고 하네요.

   

설정

자, 세팅해볼까요~ (아직 환경 구성이 안 되었습니다 마무리 되면 정리!!)

엇,, SERVER 구성 파일로 변경(SSD 경로로 파일 구성) 할 수 있구나~

   

   

   

Microsoft® SQL Server® 2014 CTP1 Product Guide 문서가 아래와 같이 다운로드를 할 수가 있습니다.

http://www.microsoft.com/en-us/download/details.aspx?id=39269&WT.mc_id=rss_alldownloads_all

   

다운로드 파일을 압축 해제하게 되면 ./documents/ 폴더 가이드 문서가 주루룩 나오네요~

SQL Server 2014 - Hekaton

SQL2014 버전에 대한 많은 정보가 공유되고 있는데, OLTP 시스템 중 인 메모리 부분이 관심이 되고 있습니다. 기존 RDBMS에서 처리 속도에 비해 16배 정도 속도 차이가 있다고 하지요.

   

평가판에 대한 일반인 오픈은 되고 있지 않은 상태입니다.

아래의 링크를 통해서 알림 등록 가능합니다.

http://www.microsoft.com/en-us/sqlserver/sql-server-2014.aspx?WT.mc_id=OO_Technet_Home_General_EN_US

   

   

   

칼렌님이 올려주신 white paper에는 2014에 대한 내부 아키텍쳐 정보를 살짝 볼 수 있습니다.

SQL Server In-Memory OLTP Internals Overview for CTP1
http://sqlblog.com/blogs/kalen_delaney/archive/2013/06/05/hekaton-whitepaper.aspx

   

안습이게도 모두 영어네요 bb… 영어진짜 못하는데~ bb        

   

SQL Server 엔진에 포함된 In-Memory Component들… 모든 클라이언트들은 TDS 핸들러를 통해서 동일한 방법으로 접속을 합니다. Disk기반 테이블과 메모리 최적화 테이블들의 접근하는 컴포넌트가 다르며, 가장 큰 차이점은 메모리 기반 테이블을 엑세스 할때 디스크로부터 캐쉬 page를 읽을 필요가 없다.

   

  • 트랜잭션 로그도 기존 디스크 기반과 동일하게 기록이 된다.
  • SCHEMA_ONLY 옵션으로 메모리에만 존재할 수 있는 테이블 옵션. 휘발성인 데이터에 쓰면 좋겠다. 예를 들어 자주 쓰는 정보이지만 메모리에만 넣어두면 좋을 것들~~ 카운팅, 최신 뉴스~ 등등. 웹 세션 상태, . 좀더 고민해봐야겠다
  • 메모리 기반 테이블들은 전통적인 B-Tree 형태로 저장하지 않는다. 해쉬 인덱스 기반으로 특별한 BW-Tree를 사용하여 저장 한다. 모든 테이블은 적어도 하나의 인덱스를 가져야 하며, 디스크 기반의 테이블들과 같이 힙 형태로 저장할 수 없다.
  • 메모리 기반 테이블은 완전히 낙관성 다중 버전 동시성 제어를 사용하며, 이에 대기할 필요가 없다.
  • natively compiled stored procedures으로 최고 성능 실행을 얻을 수 있다.

   

   

SQL2014는 64bit 기반의 OS에서만 설치 가능하다.

   

데이타베이스 생성

기존 데이타베이스 생성 방식과 비슷하며, 추가적으로 CONTAINS MEMORY_OPTIMIZED_DATA 키워드로 메모리 기반 테이블용 파일 그룹을 지정 한다.

  • 바이너리 collation을 지정
  • 메모리 기반 테이블 경로 지정, 만약 메모리 기반 테이블이 여러 개 있을 경우 각각의 경로를 지정을 해야 할 듯?

   

테이블 생성

   

지원되는 데이터 타입

XML, CLR, MAX 데이터 형식으로 지정하는게 없고, n으로 특정 크기를 지정해야 한다. .

   

   

기존 테이블 생성한는 방법과 동일하며, 아래와 같이 빨간줄 부분만 추가하면 된다.

인 메모리 기반 제약 사항

   

[펌] SQL2014 공개 자료

http://sqlblog.com/blogs/kalen_delaney/archive/2013/06/05/hekaton-whitepaper.aspx

좋은 자료네요. 


큭.... 인메모리 테이블들은 아래와 같이 제약 사항이 있네요. 헙헙..

There are only a few limitations when creating memory-optimized tables, in addition to the data type limitations already listed.

  • No DML triggers
  • No FOREIGN KEY or CHECK constraints
  • No IDENTITY columns
  • No UNIQUE indexes other than for the PRIMARY KEY

  • A maximum of 8 indexes, including the index supporting the PRIMARY KEY