16

Hiện đang làm việc trên ứng dụng ASP.Net MVC 4 sử dụng Entity Framework 5. Được sử dụng CodeFirst cho giai đoạn phát triển ban đầu. Nhưng giờ đây đã tắt tính năng Tự động di chuyển và thiết kế các bảng mới trực tiếp bằng SSMS và viết POCO. Mọi thứ đều hoạt động tốt.Cơ sở dữ liệu SQL Azure Windows - Danh tính Tự động tăng cột bỏ qua giá trị

Gần đây, đã xác định sự cố kỳ lạ trong Sản xuất. Các bản ghi trong một trong các bảng được thiết kế ban đầu đã bỏ qua giá trị nhận dạng tự động gia tăng thêm hơn 900 số. Điều này đã xảy ra 3 lần trong vòng 3 tháng qua. Đã gỡ lỗi ứng dụng cục bộ nhưng không thể tái tạo. Không có bất kỳ mô hình hoặc xu hướng quan sát.

mẫu:

public class Enquiry 
{ 
    [Key] 
    [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)] 
    public Int64 EnquiryId { get; set; } 

    [Required] 
    public int UserId { get; set; } 

    [Required] 
    public byte Bid { get; set; } 

    ... 

    [Required] 
    public DateTime Created { get; set; } 

    [Required] 
    public DateTime Modified { get; set; } 
} 

public class EnquiryDetail 
{ 
    [Key] 
    public Int64 EnquiryId { get; set; } 

    [Required] 
    public int CreditScore { get; set; } 

    [Required] 
    public byte BidMode { get; set; } 

    public virtual Enquiry Enquiry { get; set; } 
} 

DBContext:

public class EscrowDb : DbContext 
{ 

    public EscrowDb() 
     : base("name=DefaultConnection") 
    { 

    } 
    public DbSet<Enquiry> Enquiries { get; set; } 
    public DbSet<EnquiryDetail> EnquiryDetails { get; set; } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Conventions.Remove<PluralizingTableNameConvention>(); 
     modelBuilder.Entity<EnquiryDetail>() 
      .HasRequired<Enquiry>(ed => ed.Enquiry) 
      .WithRequiredDependent(e => e.EnquiryDetail); 
    } 
} 

Bộ điều khiển:

[Authorize] 
public class EnquiryController : Controller 
{ 
    private EscrowDb _db = new EscrowDb(); 

    [HttpPost] 
    [ValidateAntiForgeryToken] 
    public ActionResult Create(EnquiryViewModel core) 
    { 
     var enquiry = new Enquiry(); 
     // Some code to set properties using passed ViewModel 
     ... 

     var enquiryDetail = new EnquiryDetail(); 
     // Some code to set properties using passed ViewModel 
     ... 

     enquiry.EnquiryDetail = enquiryDetail; 

     _db.Enquiries.Add(enquiry); 
     _db.SaveChanges(); 
    } 
} 

Tất cả các mã này đã làm việc f cho đến nay, ngoại trừ giá trị nhận dạng bị bỏ qua một cách không thường xuyên bởi những khoảng trống lớn gần 1000 số.

Có ai gặp phải vấn đề như vậy không? Hãy chia sẻ suy nghĩ của bạn.

+0

Xem tại đây: https://connect.microsoft.com/SQLServer/feedback/details/739013/alwayson-failover -results-in-reseed-of-identity –

+0

@Rosiek, tôi không thấy bất kỳ giải pháp sẵn sàng sử dụng tốt nào có tại có thể được áp dụng cho SQL Azure Web Edition trong MS Cloud. – Santosh

+0

Tôi thấy cùng một vấn đề. Bất kỳ may mắn nào tìm ra điều này? –

Trả lời

18

Bạn có thể không may mắn nếu bạn cần loại bỏ những khoảng trống này.

Tôi tự mình gặp sự cố này khi tôi đang phát triển/thử nghiệm một ứng dụng mới. Tôi đang intuiting những gì đang xảy ra ở đây trong sql azure dựa trên những gì tôi đã đọc về sql server 2012. Tôi đã không thể tìm thấy bất kỳ tài liệu nào về điều này cho sql azure.

Từ những gì tôi đã đọc đây là một tính năng xuất hiện dưới dạng lỗi IMO. Trong máy chủ Sql 2012 Microsoft đã thêm khả năng tạo chuỗi. Trình tự ghi lại những giá trị đã được sử dụng trong các khối 1000. Vì vậy, cho phép nói chuỗi của bạn đang tiến triển ... 1, 2, 3, 4, 5 ... và sau đó máy chủ sql của bạn khởi động lại. Vâng trình tự đã lưu một thực tế là khối 1-1000 đã được sử dụng để nó nhảy bạn đến 1000 tiếp theo .... vì vậy giá trị tiếp theo của bạn là 1001, 1002, 1003, 1004 .... Điều này cải thiện hiệu suất của chèn khi sử dụng chuỗi, nhưng có thể dẫn đến những khoảng trống bất thường. Có một giải pháp cho điều này cho chuỗi của bạn. Khi xác định trình tự bạn thêm tham số "NOCACHE" để nó không lưu khối 1000 tại một thời điểm. See here for more documentation.

Trường hợp này trở thành vấn đề là các cột Identity dường như đã được thay đổi để sử dụng cùng một mô hình này. Vì vậy, khi máy chủ của bạn, hoặc trong trường hợp này sql Azure dụ của bạn khởi động lại bạn có thể nhận được khoảng trống lớn (1000's) trong cột nhận dạng của bạn bởi vì nó là bộ nhớ đệm khối lớn là "sử dụng". Có một giải pháp cho điều này cho máy chủ sql năm 2012. Bạn có thể chỉ định cờ khởi động t272 để hoàn nguyên danh tính của bạn để sử dụng mô hình sq2 server 2008 r2 cũ. Vấn đề là tôi không biết (nó có thể không được) của làm thế nào để xác định điều này trong sql Azure. Không thể tìm thấy tài liệu. See this thread for more details on sql server 2012.

Check the documentation of identity here in the msdn. Cụ thể phần "Giá trị liên tiếp sau khi khởi động lại máy chủ hoặc các lỗi khác".Đây là những gì nó nói:

giá trị liên tiếp sau khi khởi động lại máy chủ hoặc thất bại khác -SQL server có thể bộ nhớ cache các giá trị bản sắc vì lý do hiệu suất và một số các giá trị giao có thể bị mất trong một thất bại cơ sở dữ liệu hoặc máy chủ khởi động lại. Điều này có thể dẫn đến những khoảng trống trong giá trị danh tính khi chèn. Nếu không thể chấp nhận các khoảng trống thì ứng dụng sẽ sử dụng trình tự phát trình tự với tùy chọn NOCACHE hoặc sử dụng cơ chế riêng của chúng để tạo các giá trị khóa.

Vì vậy, nếu bạn cần có giá trị liên tiếp, bạn có thể thử chỉ định chuỗi bằng nocache thay vì dựa vào cột nhận dạng của bạn. Chưa tự mình thử, but sounds like you'll have trouble getting this to work with entity framework.

Xin lỗi nếu điều này không giúp được gì nhiều, nhưng ít nhất đó là một số thông tin về trải nghiệm của bạn.

0

Dường như không có TF 272 hoạt động xung quanh cho SQL Azure. Tôi chỉ nhận thấy vấn đề trong 2 bảng (khoảng trống 999 và 1000) và nghĩ rằng đó là một vi phạm an ninh trước khi kiểm tra hai bảng và kiểm tra các bản ghi được chèn vào. Xem mục cuối cùng của this MS TechNet discussion để biết chi tiết. Loại tái đảm bảo, nhưng trông giống như một lỗi hơn một tính năng.

0

Tôi cũng gặp vấn đề này và cho đến lúc này tôi không thể tìm thấy bất kỳ cách nào, có vẻ như thực thể có lỗi hoặc một cái gì đó như thế này. tôi tìm kiếm trên internet nhưng không có gì chi tiết

1

Thử cách chèn lại với phương pháp kích hoạt. Tôi tin rằng điều này sẽ giải quyết nó example of its use và xem thêm hướng dẫn tại liên kết đó.

USE [TEST] 

CREATE TABLE TEST(ID INT IDENTITY(1,1),VAL VARCHAR(10)) 

CREATE TRIGGER TGR_TEST_IDENTITY ON TEST 
FOR INSERT 
AS 
DECLARE @RESEEDVAL INT 
SELECT @RESEEDVAL = MAX(ID) FROM TEST 
DBCC CHECKIDENT('TEST', RESEED, @RESEEDVAL) 

INSERT INTO TEST(VAL)VALUES('a') 

SELECT * FROM TEST 

Từ 'DBCC CHECKIDENT' không được hỗ trợ trong Azure bây giờ bạn có thể sử dụng cách tiếp cận trong link này Trong liên kết mà tôi đã nhận một số quanh công việc

  1. Sử dụng GUID như chính khi sử dụng chìa khóa tự động của SqlAzure
  2. Nếu phím số nguyên như trường hợp của tôi cho phép chèn bản ghi và quay lại và xóa nó và chèn lại bằng khóa bên phải bằng cách Turing tắt danh tính với đặt identity_insert XXXTable bật - về cơ bản, tắt IDENTITY

và sau đó quay trở lại danh tính một lần nữa khi tôi thông qua với sự chèn với chính quyền sử dụng

bộ IDENTITY_INSERT XXXTable tắt --this cơ bản bật SẮC

Lưu ý: đây không phải là một tốt giải pháp cho một bảng đang nhận được yêu cầu chèn lớn nhưng có thể hữu ích cho ai đó đang tìm kiếm một cách tạm thời ra ngoài

+0

đây là phép thuật cho một máy chủ được khởi động lại thường xuyên và một bảng hiếm khi nhận được hàng! cảm ơn, được trên tất cả các interwebz tìm kiếm một nhanh chóng & bẩn – user230910

+0

Bạn được chào đón rất vui vì nó rất hữu ích cho bạn –

Các vấn đề liên quan