সনাক্তকরণ বৃদ্ধি এসকিউএল সার্ভার ডাটাবেসে ঝাঁপিয়ে পড়েছে


126

Feeএসকিউএল সার্ভার ২০১২ ডাটাবেস শনাক্তকরণের বর্ধিত কলামের "রিসিপ্টনো" কলামের আমার একটি সারণিতে হঠাৎ নিম্নলিখিত দুটি বিষয়ের উপর নির্ভর করে 1 এর পরিবর্তে 100 এর দিকে ঝাঁপিয়ে পড়া শুরু হয়েছিল started

  1. এটি যদি 1205446 হয় তবে তা জাম্প হয় 1206306, যদি এটি 1206321 হয় তবে এটি লাফ দিয়ে 1207306 এবং এটি যদি 1207314 হয় তবে এটি লাফিয়ে 1208306 এ যায় I আমি আপনাকে কী নোট করতে চাই তা হ'ল শেষ তিনটি সংখ্যা স্থির থাকে অর্থাৎ 306 যখনই ঝাঁপ দেয় নিম্নলিখিত ছবিতে প্রদর্শিত হিসাবে ঘটে।

  2. এই সমস্যাটি ঘটে যখন আমি আমার কম্পিউটার পুনরায় চালু করি

এখানে চিত্র বর্ণনা লিখুন


আপনি যদি order by ReceiptNoআপনার ক্যোয়ারিতে যুক্ত হন তবে সেই রেকর্ডগুলি কি আসলেই নেই? আপনি কি নিশ্চিত যে যখন রেকর্ডগুলি sertedোকানো হচ্ছে তখন কোনও ত্রুটি নেই? যদি কোনও রেকর্ড সন্নিবেশ করানোর চেষ্টা করে এবং ব্যর্থত হয় তবে পরিচয় বৃদ্ধি পাবে, রেকর্ড মুছে ফেলা হলে একই জিনিস। রেকর্ডগুলি মুছে ফেলা হলে ReceiptNoরিসেট হয় না। আপনি কি টেবিলের জন্য তৈরি টেবিল পোস্ট করতে পারেন Fee?
টেরিন

4
প্রথম প্রশ্নটি - এটি কেন ব্যাপার? এটি একটি নির্বিচারে অনন্য আইডি হওয়া উচিত
অ্যান্ড্রু

1
এটি কি কোনও সার্ভারে চলছে বা এটি সম্ভবত কোনও ডেস্কটপে প্রকাশ করা হচ্ছে? ভাবছেন কেন পরিষেবাটি ঘন ঘন পুনরায় চালু হচ্ছে?
মার্টিন স্মিথ

@ ব্লুয়েফেট আমি জানি যখন ত্রুটি ঘটে তখন পরিচয় বৃদ্ধি হয়। আমি 100% নিশ্চিত যে কোনও ত্রুটি নেই। সারণি সন্নিবেশ করানোর জন্য আমি টেবিল এবং সঞ্চিত পদ্ধতিটি যুক্ত করে আমার প্রশ্নটি সম্পাদনা করছি।
কাশিফ

@ কাশিফ - 99% নিশ্চিত যে এটির প্রয়োজন নেই। ঠিক 1000 দ্বারা জাম্প ( 1206306, 1207306, 1207806) এর অর্থ কানেক্ট আইটেম থ্রেড ব্যাখ্যা প্রায় অবশ্যই প্রযোজ্য।
মার্টিন স্মিথ

উত্তর:


158

এসকিউএল সার্ভার ২০১২ সাল থেকে পারফরম্যান্স উন্নতির কারণে আপনি এই আচরণটির মুখোমুখি হচ্ছেন।

এটি এখন ডিফল্টরূপে 1,000 এর ক্যাশে আকার ব্যবহার করে যখন IDENTITYকোনও intকলামের জন্য মান বরাদ্দ করা হয় এবং পরিষেবাটি পুনরায় চালু করা অব্যবহৃত মানগুলি "হারাতে" পারে (ক্যাশে আকারটি 10,000 bigint/ এর জন্য numeric)।

এটি ডকুমেন্টেশনে উল্লেখ করা হয়েছে

এসকিউএল সার্ভার পারফরম্যান্স কারণে পরিচয় মানগুলি ক্যাশে করতে পারে এবং একটি নির্ধারিত মানগুলির একটি ডাটাবেস ব্যর্থতা বা সার্ভার পুনঃসূচনা করার সময় হারিয়ে যেতে পারে। এটি সন্নিবেশ করার পরে পরিচয় মান ফাঁক হতে পারে। যদি ফাঁকগুলি গ্রহণযোগ্য না হয় তবে অ্যাপ্লিকেশনটির মূল মান উত্পন্ন করতে নিজস্ব পদ্ধতি ব্যবহার করা উচিত। NOCACHEবিকল্পের সাথে সিকোয়েন্স জেনারেটর ব্যবহার করা কোনও লেনদেনের মধ্যে ফাঁকিকে সীমাবদ্ধ করতে পারে যা কখনই প্রতিশ্রুতিবদ্ধ হয় না।

আপনি যে ডেটা দেখিয়েছেন তা দেখে মনে হচ্ছে এটি 22 ডিসেম্বরের ডেটা এন্ট্রি করার পরে ঘটেছিল যখন এটি এসকিউএল সার্ভার পুনরায় আরম্ভ করার পরে মানগুলি সংরক্ষণ করে 1206306 - 1207305। 24 - 25 ডিসেম্বরের জন্য ডেটা এন্ট্রি করার পরে আরও একটি পুনরায় আরম্ভ করা হয়েছিল এবং এসকিউএল সার্ভার 1207306 - 120830528 তম জন্য এন্ট্রিগুলিতে দৃশ্যমান পরবর্তী পরিসীমা সংরক্ষণ করে ।

আপনি যদি অস্বাভাবিক ফ্রিকোয়েন্সি সহ পরিষেবাটি পুনরায় চালু না করেন তবে ডেটাটাইপ দ্বারা অনুমোদিত মানগুলির পরিসীমাতে কোনও "হারানো" মানগুলি কোনও উল্লেখযোগ্য ঝুঁকি ফেলতে পারে না তাই সেরা নীতি সম্পর্কে এটি চিন্তা করা উচিত নয়।

যদি এটি কোনও কারণে আপনার কাছে একটি বাস্তব সমস্যা হয় তবে সম্ভাব্য কিছু কাজের ক্ষেত্রগুলি হ'ল ...

  1. আপনি SEQUENCEএকটি পরিচয় কলামের পরিবর্তে ব্যবহার করতে পারেন এবং উদাহরণস্বরূপ একটি ছোট ক্যাশে আকার নির্ধারণ করতে পারেন NEXT VALUE FORএবং কলাম ডিফল্টে ব্যবহার করতে পারেন ।
  2. অথবা ট্রেস পতাকা 272 প্রয়োগ করুন যা IDENTITYবরাদ্দটি 2008 আর 2 পর্যন্ত সংস্করণ হিসাবে লগড করে তোলে । এটি সমস্ত ডাটাবেসের ক্ষেত্রে বিশ্বব্যাপী প্রযোজ্য।
  3. অথবা, সাম্প্রতিক সংস্করণগুলির ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE = OFFজন্য, একটি নির্দিষ্ট ডাটাবেসের জন্য পরিচয় ক্যাচিং অক্ষম করতে কার্যকর করুন ।

আপনার সচেতন হওয়া উচিত এই কাজের ক্ষেত্রগুলির মধ্যে কোনওরই কোনও ফাঁকির আশ্বাস নয়। এটি কখনই তার নিশ্চয়তা দেয় নি IDENTITYকারণ এটি কেবল সারণীতে সারণী প্রবেশ করিয়েই সম্ভব হবে। আপনি যদি একটি ফাঁকবিহিন কলাম প্রয়োজন আপনি তুলনায় বিভিন্ন সমাধান ব্যবহার করতে হবে পারেন IDENTITYবাSEQUENCE


1
আপনি যা বলেছিলেন তা যাচাই করতে আমি কিছু মান সন্নিবেশ করলাম এবং 1208309, 1208310 পেয়েছি এবং তারপরে আমি সার্ভারটি পুনরায় চালু করেছি এবং তারপরে আমি সারিটি যুক্ত করার সাথে সাথে আমি 1209309 পেয়েছি যার অর্থ আপনি যা বলেছেন তা একেবারে ঠিক। অনেক ধন্যবাদ. এখন আপনি আমাকে কীভাবে এই সমস্যাটি সমাধান করতে পারেন আমাকে বলতে পারেন। আপনি কি আমাকে 2012 এর পরিবর্তে এসকিএল সার্ভার 2008 ব্যবহার করার পরামর্শ দিবেন যা আমি আগে 2012 ব্যবহার করেছিলাম বা 2012 ব্যবহার করেও এই সমস্যার সমাধান হতে পারে ??
কাশিফ 21

1
@কাশিফ - আসলেই কি এটি আপনার সমস্যা? এমনকি যদি আপনি একদিনে 1000 টি পরিচয় মান ব্যবহার করেন তবে মানগুলি শেষ হওয়ার আগে 2 মিলিয়ন দিন লাগবে। আপনি যদি পুরানো আচরণটি চান তবে আপনি এসকিউএল সার্ভারটিকে ট্রেস ফ্ল্যাগ 272 দিয়ে শুরু করতে সেট করতে পারেন বা আপনি এর SEQUENCEপরিবর্তে একটি ব্যবহার করতে পারেন IDENTITYএবং এর আকারটি ক্যাশের আকারের জন্য সিকোয়েন্স সেট করতে পারেন 0
মার্টিন স্মিথ

আমার সমাধানের জন্য আপনার কাছ থেকে প্রচুর চিত্তাকর্ষক এবং সন্তোষজনক উত্তর পেয়েছি ধন্যবাদ প্রচুর।
কাশিফ

আসলে আপনার কাছ থেকে CREATE TABLEআমি দেখতে পেয়েছি যে আপনি ব্যবহার করছেন numeric(7)এবং নাম্বারটি শুরু করেছেন যার 1200001অর্থ আপনি 8,799যদি প্রতিদিন 1000 ব্যবহার করেন তবে আপনি দিনগুলি (24 বছর) পরে রান আউট হয়ে যাবেন ।
মার্টিন স্মিথ

আসল মান "লাফানো" ব্যবহৃত কলামের ধরণের উপর নির্ভরশীল বলে মনে করা হচ্ছে। উদাহরণস্বরূপ, একটি big intকলাম সাধারণত পুনরায় আরম্ভের জন্য 10,000 দ্বারা "লাফিয়ে" যাবে।
স্টারপাইলট

60

এসকিউএল সার্ভার পুনরায় চালু করার পরে এই সমস্যাগুলি দেখা দেয়।

সমাধানটি হ'ল:

  • এসকিউএল সার্ভার কনফিগারেশন ম্যানেজার চালান ।

  • এসকিউএল সার্ভার পরিষেবাদি নির্বাচন করুন ।

    এসকিউএল সার্ভার কনফিগারেশন ম্যানেজার

  • সঠিক পছন্দ এসকিউএল সার্ভারকে এবং বৈশিষ্ট্য নির্বাচন করুন ।

  • স্টার্টআপ প্যারামিটারের অধীনে খোলার উইন্ডোতে , টাইপ করুন -T272এবং ক্লিক করুন যোগ করুন , তারপরে প্রয়োগ বোতাম টিপুন এবং পুনরায় চালু করুন।

    এসকিউএল সার্ভার সূচনা পরামিতি


1
এই পদ্ধতিটি আসলেই কাজ, অনেক অনেক ধন্যবাদ! এবং এখানে যেমন বলা হয়েছে , এই সমস্যাটি এসকিউএল সার্ভারে সংশোধিত হবে না 2012 এবং এর পরিষেবা প্যাকগুলি - কেবলমাত্র পরবর্তী সংস্করণে প্রকাশিত হবে।
খণ্ডিত

2
স্বতন্ত্র ডাটাবেসগুলিতে ট্রেস পতাকা প্রয়োগ করার কোনও উপায় আছে কি? আমি পুরো সার্ভারে এই পরিবর্তনটি আনতে চাই না কারণ আমার কাছে তৃতীয় পক্ষের ডেটাবেস রয়েছে এবং আমি নিশ্চিত নই যে এটি কীভাবে তাদের প্রভাব ফেলবে।
এজ এরজোজ

1
আমি কারণগুলি অনুসরণ করি নি, তবে দৃশ্যত কিছু ব্যবহারকারীর এটির কাজ পেতে লোয়ার কেস "টি" ব্যবহার করতে হয়েছিল। উপরের মন্তব্যে ফ্রেগমেন্ট পোস্ট করা লিংকটি দেখুন।
সেভেজ

33

থেকে SQL Server 2017+আপনি ব্যবহার করতে পারে ALTER ডেটাবেস scoped কনফিগারেশন :

IDENTITY_CACHE = {চালু | বন্ধ}

ডাটাবেস পর্যায়ে পরিচয় ক্যাশে সক্ষম বা অক্ষম করে। ডিফল্ট চালু আছে। আইডেন্টিটি ক্যাচিং আইডেন্টিটি কলাম সহ টেবিলগুলিতে INSERT পারফরম্যান্স উন্নত করতে ব্যবহৃত হয়। সার্ভারটি অপ্রত্যাশিতভাবে পুনরায় চালু হয় বা কোনও গৌণ সার্ভারে ব্যর্থ হয় সে ক্ষেত্রে পরিচয় কলামের মানগুলির ফাঁকগুলি এড়াতে, IDENTITY_CACHE বিকল্পটি অক্ষম করুন। এই বিকল্পটি বিদ্যমান এসকিউএল সার্ভার ট্রেস পতাকা 272 এর মতো, এটি কেবল সার্ভার স্তরের পরিবর্তে ডাটাবেস স্তরে সেট করা যায়।

(...)

ছ। IDENTITY_CACHE সেট করুন

এই উদাহরণটি পরিচয় ক্যাশে অক্ষম করে।

ALTER DATABASE SCOPED CONFIGURATION SET IDENTITY_CACHE=OFF ;

25

আমি জানি আমার উত্তর পার্টিতে দেরি হতে পারে। তবে আমি এসকিউএল সার্ভার 2012-এ স্টার্ট আপ স্টোরেজ পদ্ধতি যুক্ত করে অন্যভাবে সমাধান করেছি।

মাস্টার ডিবিতে নিম্নলিখিত সঞ্চিত পদ্ধতি তৈরি করুন।

USE [master]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[ResetTableNameIdentityAfterRestart]
AS
BEGIN

begin TRAN
    declare @id int = 0
    SELECT @id =  MAX(id) FROM [DatabaseName].dbo.[TableName]
    --print @id
    DBCC CHECKIDENT ('[DatabaseName].dbo.[TableName]', reseed, @id)
Commit

END

তারপরে নিম্নলিখিত সিনট্যাক্স ব্যবহার করে এটি শুরুতে যুক্ত করুন।

EXEC sp_procoption 'ResetOrderIdentityAfterRestart', 'startup', 'on';

আপনার কয়েকটি টেবিল থাকলে এটি একটি ভাল ধারণা। তবে আপনাকে যদি অনেকগুলি টেবিলের জন্য করতে হয় তবে এই পদ্ধতিটি এখনও কাজ করে তবে একটি ভাল ধারণা নয়।


ভাল ধারণা। তবে এটি নির্ভর করে টেবিলের জন্য কাজ করে না, তাই না? মানে, এটি কি বিদেশী কী মানগুলি ঠিক করে?
rom5jp

@ rom5jp ফিক্সিং এফকে এই উত্তরটির মূল বিষয় নয়। এটি একটি সারণীর সম্ভাব্য পরবর্তী পিকে মান ঠিক করার বিষয়ে। যতক্ষণ না ম্যাক্স (আইডি) কোনও এফকে না থাকে, এটি কাজ করা উচিত।
জিয়ারা 4

14

আকার নির্বিশেষে অনেক বিকাশকারী এবং অ্যাপ্লিকেশনগুলির মধ্যে এটি এখনও একটি খুব সাধারণ সমস্যা।

দুর্ভাগ্যক্রমে উপরের পরামর্শগুলি সমস্ত পরিস্থিতিতে ঠিক করে না, যেমন ভাগ করা হোস্টিং, আপনি -t272 স্টার্টআপ প্যারামিটার সেট করতে আপনার হোস্টের উপর নির্ভর করতে পারবেন না।

এছাড়াও, যদি আপনার কাছে বিদ্যমান সারণী থাকে যা প্রাথমিক কীগুলির জন্য এই পরিচয় কলামগুলি ব্যবহার করে, তবে এই কলামগুলি ফেলে দেওয়া এবং বিএস সিকোয়েন্সটি কাজের ভিত্তিতে নতুনকে পুনরায় তৈরি করা একটি বিশাল প্রচেষ্টা। সিক্যুয়েন্স ওয়ার্কারআউন্ড কেবলমাত্র যদি আপনি এসকিউএল ২০১২+ তে স্ক্র্যাচ থেকে নতুন টেবিলগুলি ডিজাইন করেন

নীচের লাইনটি হল, আপনি যদি সিকিএল সার্ভার 2008R2 এ থাকেন তবে এটি চালিয়ে যান। সিরিয়াসলি, এটি থাকুন। মাইক্রোসফ্ট স্বীকার না করা পর্যন্ত যে তারা একটি বিশাল বাগ প্রবর্তন করেছে, এটি এখনও স্কেল সার্ভার 2016-এ রয়েছে, ততক্ষণ পর্যন্ত এটির মালিকানা না পাওয়া এবং এটি ফিক্স না করা পর্যন্ত আমাদের আপগ্রেড করা উচিত নয়।

মাইক্রোসফ্ট সরাসরি একটি ব্রেকিং পরিবর্তন আনল, অর্থাৎ তারা একটি ওয়ার্কিং এপিআই ভেঙে দিয়েছে যা আর নকশা অনুযায়ী কাজ করে না, এই কারণে যে তাদের সিস্টেমটি তাদের পুনরায় আরম্ভের সময় তাদের বর্তমান পরিচয়টি ভুলে যায়। ক্যাশে বা কোনও ক্যাশে নেই, এটি অগ্রহণযোগ্য এবং ব্রায়ান নামে মাইক্রোসফ্ট বিকাশকারীকে এটির মালিকানা প্রয়োজন, পরিবর্তে বিশ্বকে জানান যে এটি "নকশা দ্বারা" এবং একটি "বৈশিষ্ট্য"। অবশ্যই, ক্যাচিং একটি বৈশিষ্ট্য, তবে পরবর্তী পরিচয়টি কী হওয়া উচিত তার ট্র্যাক হারাতে এটি কোনও বৈশিষ্ট্য নয়। এটি একটি ফ্রিকেন বিউজি !!!

আমি যে কাজটি ব্যবহার করেছি তা ভাগ করে নেব, কারণ আমার ডিবি শেয়ার্ড হোস্টিং সার্ভারগুলিতে রয়েছে, এছাড়াও আমি আমার প্রাথমিক কী কলামগুলি ছাড়ছি এবং পুনরায় তৈরি করছি না, এটি একটি বিশাল পিআইটিএ হবে।

পরিবর্তে, এটি আমার লজ্জাজনক হ্যাক (তবে মাইক্রোসফ্ট প্রবর্তিত এই পস বাগের মতো লজ্জাজনক নয়)।

হ্যাক / ফিক্স:

আপনার সন্নিবেশ কমান্ডগুলির আগে, প্রতিটি সন্নিবেশ করার আগে আপনার পরিচয়টি পুনরায় পরীক্ষা করুন। এই সংশোধনটি কেবলমাত্র তখনই প্রস্তাবিত হয় আপনার যদি আপনার SQL সার্ভার উদাহরণস্বরূপ প্রশাসকের নিয়ন্ত্রণ না থাকে, অন্যথায় আমি সার্ভার পুনরায় চালু করার পরামর্শ দিই।

declare @newId int -- where int is the datatype of your PKey or Id column
select @newId = max(YourBuggedIdColumn) from YOUR_TABLE_NAME
DBCC CheckIdent('YOUR_TABLE_NAME', RESEED, @newId)

আপনার প্রবেশের ঠিক আগে 3 টি লাইন এবং আপনার যেতে ভাল হওয়া উচিত। এটি প্রকৃতপক্ষে পারফরম্যান্সকে প্রভাবিত করবে না, অর্থাত্ এটি অদম্য।

গুডলাক।


7

শনাক্তকরণ মানগুলি জাম্প দেওয়ার জন্য অনেকগুলি সম্ভাব্য কারণ রয়েছে। এগুলি রোলকড ব্যাক সন্নিবেশ থেকে শুরু করে পরিচয় ব্যবস্থাপনার মধ্যে রয়েছে for আপনার ক্ষেত্রে এটি কী কারণে ঘটছে আমি আপনার সিস্টেমে কিছু সময় ব্যয় না করে বলতে পারি না।

আপনার অবশ্য জানা উচিত, কোনও ক্ষেত্রেই আপনি কোনও পরিচয় কলামকে দ্বন্দ্ব হিসাবে ধরে নিতে পারবেন না। এখানে অনেকগুলি জিনিস রয়েছে যা ফাঁক হতে পারে।

আপনি এখানে এই বিষয়ে একটু বেশি তথ্য পেতে পারবেন: http://sqlity.net/en/792/the-gap-in-the-identity-value-sequence/

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.