SQL Server Express ჰოსტინგი: ლიმიტები და როდისაა საკმარისი

SQL Server Express არის Microsoft SQL Server-ის უფასო edition, production-ისთვის ლიცენზირებული, და ის იგივე ბაზის ძრავია, რაც ფასიან edition-ებში, რამდენიმე მკაცრი ზღვრით. SQL Server 2022-ში ეს ზღვრებია: 10 GB მონაცემი თითო ბაზაზე, დაახლოებით 1.4 GB მეხსიერება buffer pool-ისთვის, ერთ socket-სა და ოთხ ბირთვს შორის ნაკლები და SQL Server Agent-ის გარეშე. ტიპური ვებ-აპლიკაციისთვის, შიდა ინსტრუმენტისთვის, თამაშის backend-ისთვის ან პატარა SaaS-ისთვის ეს საკმარისია - ხშირად წლების განმავლობაში. საკმარისი აღარ არის, როცა ერთი ბაზა 10 GB-ს უახლოვდება, როცა working set 1.4 GB cache-ში აღარ ეტევა, ან როცა ძრავის შიგნით დაგეგმილი დავალებები, რეპლიკაცია ან მაღალი ხელმისაწვდომობა გჭირდება. ეს პოსტი თითოეულ ლიმიტს გადის: რა ხდება, როცა მას მიაღწევ, როგორ თვალყური ადევნო და რა არის ის გულწრფელი წერტილი, როცა სხვა რამეზე უნდა გადახვიდე.

რა არის SQL Server Express#

Microsoft SQL Server-ს edition-ებად უშვებს, რომლებიც ერთ კოდის ბაზას იზიარებს: Enterprise, Standard, Web (ჰოსტინგის პროვაიდერებისთვის), Developer (Enterprise-ის შესაძლებლობები, ლიცენზირებული მხოლოდ დეველოპმენტისა და ტესტირებისთვის) და Express. Express უფასო production edition-ია. ის იმავე query optimiser-ს, იმავე storage ძრავს და იმავე T-SQL-ს უშვებს, რასაც დანარჩენები, და Express-ზე შექმნილი ბაზის backup შეიძლება აღდგეს იმავე ან უფრო ახალი ვერსიის Standard-ზე ან Enterprise-ზე კონვერტაციის გარეშე.

SQL Server 2016 SP1-დან შესაძლებლობების გრძელი სია, რომელიც ადრე მხოლოდ Enterprise-ში იყო, ყველა edition-ში მუშაობს, Express-ის ჩათვლით. ამან შეცვალა, რას ნიშნავს "Express": ის აღარ არის შეკვეცილი ძრავი, ის სრული ძრავია მოცულობის ლიმიტებით.

Express-ში ხელმისაწვდომია:

• Columnstore ინდექსები, in-memory OLTP (memory-optimised ცხრილები), ცხრილების partitioning და მონაცემთა კომპრესია, Express-ის მეხსიერების ზღვრებში.
• Row-level security, dynamic data masking და Always Encrypted.
• Temporal ცხრილები, JSON ფუნქციები, window ფუნქციები, STRING_AGG და თანამედროვე T-SQL-ის დანარჩენი ნაწილი.
• Query Store, query plan-ებისა და წარმადობის დროში თვალყურის სადევნებლად. Query Store და ნელი query-ები განიხილავს, როგორ გამოიყენო.
• Full recovery model და ტრანზაქციის ლოგის backup-ები, ამიტომ point-in-time აღდგენა შესაძლებელია.

Express-ში მიუწვდომელია:

• SQL Server Agent, ჩაშენებული დავალებების გამგეგმავი. არც დაგეგმილი დავალებები, არც maintenance plan-ები, არც alert-ები.
• Backup-ის კომპრესია. Backup-ები მუშაობს; ძრავი მათ არ კუმშავს.
• Database Mail, log shipping, Always On availability group-ები და failover კლასტერები.
• რეპლიკაცია publisher-ის როლში. Express მხოლოდ subscriber შეიძლება იყოს.
• Resource Governor და Enterprise-ის სხვა სამუშაო დატვირთვის კონტროლები.

SQL Server 2022 Linux-ზეც მუშაობს, და დღეს ჰოსტირებული Express სერვერების უმეტესობა სწორედ ასე მუშაობს. ძრავი იგივეა; განსხვავება ძირითადად კიდეებზეა - ბილიკები, კონფიგურაცია mssql-conf-ით SQL Server Configuration Manager-ის ნაცვლად და რამდენიმე მხოლოდ Windows-ის შესაძლებლობა. SQL Server Linux-ზე, ახსნილი ამ განსხვავებებს გადის.

ლიმიტები დეტალურად#

10 GB ლიმიტი თითოეულ ბაზაზე ცალკე ვრცელდება და მხოლოდ მონაცემთა ფაილებს ითვლის (.mdf და ნებისმიერი .ndf), და არა ლოგის ფაილს (.ldf). ორი შედეგი ღირს, რომ პირდაპირ ითქვას. პირველი, ინსტანსს შეუძლია რამდენიმე ბაზა დაიტიოს, თითო 10 GB-მდე - ცალკეულ აპლიკაციებს ისედაც ცალკე ბაზები უნდა ჰქონდეთ, და ეს თითოეულს ზღვარს ქვემოთაც ინარჩუნებს. მეორე, დიდი ტრანზაქციის ლოგი 10 GB-ს არ ჭამს; ის შენს დისკს ჭამს, რაც ცალკე პრობლემაა და ქვემოთ განიხილება.

მეხსიერების ლიმიტი buffer pool-ის ზღვარია - მონაცემთა გვერდების cache, რომელიც განმეორებით წაკითხვას აჩქარებს - და არა მთელი პროცესის. SQL Server მეხსიერებას query plan-ებისთვის, კავშირებისთვის, დალაგებისთვის და საკუთარი კოდისთვისაც იყენებს, ამიტომ დატვირთული Express ინსტანსი ხშირად სულ 1.4 GB-ზე მეტს იყენებს. ზღვარი ნიშნავს იმას, რომ ბაზა, რომლის ხშირად წასაკითხი მონაცემები დაახლოებით 1.4 GB-ზე დიდია, დისკიდან უფრო ხშირად წაიკითხება, ვიდრე Standard-ზე. სწრაფ NVMe საცავზე ეს იმაზე ნაკლები ჯდება, ვიდრე ადრე, მაგრამ წაკითხვაზე ორიენტირებულ აპლიკაციაზე მაინც ის ლიმიტია, რომელსაც პირველს იგრძნობ.

გამოთვლითი ლიმიტი ოთხი ბირთვია. მეტ ბირთვიანი სერვერი Express-ს უფრო სწრაფს არ ხდის; ნაკლებ ბირთვიანი სერვერი Express-ს სამუშაოდ ნაკლებს აძლევს.

როგორ გაიგო, რამდენად ახლოს ხარ#

ბაზის ზომა ნებისმიერი query ფანჯრიდან შეამოწმე:

-- Size of data and log files in the current databaseSELECT name, type_desc,       size * 8 / 1024 AS size_mb,       FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS used_mbFROM sys.database_files;-- Overall, including unallocated spaceEXEC sp_spaceused;

size ფაილის გამოყოფილი ზომაა, SpaceUsed კი ისაა, რამდენი მათგანი მონაცემებს შეიცავს. 10 GB ლიმიტი მონაცემთა ფაილების გამოყოფილ ზომაზე ვრცელდება, ამიტომ მონაცემთა ფაილი, რომელიც 9.5 GB-მდე გაიზარდა და ნახევრად ცარიელია, ზღვართან უფრო ახლოსაა, ვიდრე მისი შიგთავსი გვაფიქრებინებს.

იმის სანახავად, რომელი ცხრილები იკავებს ადგილს:

SELECT TOP (20)       s.name + '.' + t.name AS table_name,       SUM(p.reserved_page_count) * 8 / 1024 AS reserved_mb,       SUM(CASE WHEN p.index_id IN (0, 1) THEN p.row_count END) AS row_countFROM sys.dm_db_partition_stats AS pJOIN sys.tables AS t ON t.object_id = p.object_idJOIN sys.schemas AS s ON s.schema_id = t.schema_idGROUP BY s.name, t.nameORDER BY reserved_mb DESC;

გაუშვი ეს ყოველთვიურად, ან ჩასვი მონიტორინგის სკრიპტში. სიის თავში მყოფი ცხრილები თითქმის ყოველთვის ლოგები, audit trail-ები, სესიები ან blob-ებია, რომელთა სამუდამოდ შენახვას არავინ გეგმავდა.

იმის სანახავად, როგორ გამოიყენება buffer pool:

SELECT DB_NAME(database_id) AS db,       COUNT(*) * 8 / 1024 AS cached_mbFROM sys.dm_os_buffer_descriptorsGROUP BY database_idORDER BY cached_mb DESC;

თუ cache-ის ჯამი ზღვარზე დგას და query-ების დაყოვნება ტრაფიკთან ერთად იზრდება, შემზღუდველი მეხსიერებაა. თუ cache-ის ჯამი ზღვარზე საგრძნობლად დაბლაა, მეხსიერება შენი პრობლემა არ არის და უფრო დიდი edition არ დაგეხმარება.

რა ხდება 10 GB-ზე#

არაფერი თანდათანობითი. როცა მონაცემთა ფაილს ზრდა სჭირდება და ზრდა ბაზას 10 GB-ს გადააცილებდა, ზრდაზე უარი ითქმება. Insert-ები და update-ები, რომლებსაც ახალი გვერდები სჭირდება, ვარდება შეცდომით, დაახლოებით ასეთით:

Could not allocate space for object 'dbo.AuditLog'.'PK_AuditLog' in database 'app'because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files,dropping objects in the filegroup, adding additional files to the filegroup, or settingautogrowth on for existing files in the filegroup.

წაკითხვა აგრძელებს მუშაობას, ამიტომაც ზოგიერთი აპლიკაცია ნახევრად ცოცხალი ჩანს: გვერდები იტვირთება, არაფერი ინახება. ALTER DATABASE, რომელიც ფაილის ლიმიტს გადაღმა გაზრდას ცდილობს, უარყოფილია შეტყობინებით ლიცენზირებული ლიმიტის, 10240 MB თითო ბაზაზე, გადაჭარბების შესახებ.

ლიმიტის ქვემოთ დაბრუნება:

1. წაშალე ის, რაც არ გჭირდება. ძველი ლოგის row-ები, ვადაგასული სესიები, soft-delete-ით მონიშნული ჩანაწერები. წაშალე ნაწილ-ნაწილ (DELETE TOP (5000) ... WHERE CreatedAt < ... ციკლში), რომ ყოველი ტრანზაქცია პატარა დარჩეს.
2. გაიტანე blob-ები. varbinary(max) სვეტებში შენახული ფაილები 10 GB-ის შევსების ყველაზე სწრაფი გზაა. ჩადე ისინი object storage-ში და ცხრილში გასაღები შეინახე.
3. შეკუმშე. Page კომპრესია (ALTER TABLE dbo.AuditLog REBUILD WITH (DATA_COMPRESSION = PAGE)) Express-ში ხელმისაწვდომია და დიდ, განმეორებად ცხრილებს ხშირად ნახევრით ან მეტით ამცირებს, ჩაწერისას გარკვეული CPU-ს ხარჯით.
4. დაყავი დანიშნულებით. საარქივო ან რეპორტინგის მონაცემები შეიძლება იმავე ინსტანსზე მეორე ბაზაში იცხოვროს, საკუთარი 10 GB-ით.

ფაილის შემდგომი შეკუმშვა (DBCC SHRINKFILE) გამოყოფილ ადგილს აბრუნებს, მაგრამ ინდექსებს ძლიერ აფრაგმენტებს; გააკეთე ეს ერთხელ დიდი გასუფთავების შემდეგ, მერე მნიშვნელოვანი ინდექსები თავიდან ააგე, და shrink განრიგში არასოდეს ჩასვა.

SQL Server Agent-ის გარეშე: დაგეგმვა მის გარეშე#

Agent-ს SQL Server-ის გაკვეთილების უმეტესობა ღამის backup-ებისთვის, ინდექსების მოვლისა და სტატისტიკის განახლებისთვის იყენებს. Express-ზე ის არ არის, ამიტომ ეს დავალებები ძრავის გარეთ გადადის. სამი მუშა ვარიანტი:

• ჰოსტის გამგეგმავი. RE:NODE-ზე SQL Server-ის გეგმებს 1-დან 4-მდე backup slot აქვს, და Schedules ჩანართი cron გამოსახულებით მიმდევრობით დავალებებს უშვებს - backup-ის ჩათვლით - ამიტომ ღამის ასლი კონფიგურაციაა და არა სკრიპტი, რომლის ცოცხლად შენახვაც გიწევს. Backup-ები ინახება იმ მანქანის გარეთ, რომელსაც იცავს, შეიძლება როტაციისგან ჩაიკეტოს, ჩამოიტვირთოს და ღილაკით აღდგეს.
• `sqlcmd` სხვა მანქანიდან ტაიმერით. Cron job ან Windows Task Scheduler-ის ჩანაწერი შენ მიერ კონტროლირებად მანქანაზე უშვებს sqlcmd-ს სკრიპტის ფაილით - BACKUP DATABASE, ინდექსების მოვლა, ყველაფერი, რაც T-SQL-ს შეუძლია. sqlcmd და bcp ბრძანების ხაზს განიხილავს, ხოლო SQL Server-ის backup და აღდგენა თავად backup-ის ბრძანებებს.
• აპლიკაციის საკუთარი დავალებების გამშვები. .NET worker service-ს ან Hangfire job-ს შეუძლია მოვლის T-SQL განრიგით გაუშვას. კარგია სტატისტიკისა და გასუფთავებისთვის; backup-ებისთვის ნაკლებად იდეალური, რადგან backup არ უნდა იყოს დამოკიდებული აპლიკაციის ჯანმრთელობაზე.

-- A minimal nightly maintenance script for sqlcmdBACKUP DATABASE [app] TO DISK = N'/var/opt/mssql/backup/app.bak'    WITH INIT, CHECKSUM, STATS = 10;EXEC sp_updatestats;

ზემოთ მოცემული backup-ის ბილიკი Linux-ის ინსტალაციებზე ნაგულისხმევი backup დირექტორიაა; ჰოსტირებულმა სერვერმა შეიძლება სხვა გამოიყენოს, ამიტომ მასზე დაყრდნობამდე შეამოწმე. .bak ფაილი, რომელიც ბაზის იმავე დისკზე რჩება, არცერთი გამოსადეგი გაგებით backup არ არის - გადაიტანე სხვაგან.

მეორე, რასაც Agent ჩვეულებრივ აკეთებს, ინდექსებისა და სტატისტიკის მოვლაა. სტატისტიკა ავტომატურად ახლდება, როცა საკმარისი row იცვლება (AUTO_UPDATE_STATISTICS ნაგულისხმევად ჩართულია), რაც პატარა ბაზების უმეტესობას ფარავს. ინდექსების თავიდან აგება SSD და NVMe საცავზე ნაკლებად მნიშვნელოვანია, ვიდრე ძველი რჩევები გვეუბნება; ინდექსი თავიდან ააგე, როცა შეგიძლია აჩვენო, რომ ფრაგმენტაცია კონკრეტულ query-ს აზიანებს, და არა ტაიმერით.

სერვერის ზომის შერჩევა Express-ისთვის#

რადგან Express მეხსიერებასა და ბირთვებს ზღუდავს, არსებობს წერტილი, რომლის მიღმაც უფრო დიდი სერვერი თავად ძრავისთვის არაფერს იძლევა.

დაახლოებით 4 GB საერთო მეხსიერების მიღმა დამატებითი RAM ძრავის მიერ ძირითადად გამოუყენებელი რჩება. ოთხ ბირთვზე მეტს Express ვერ იყენებს. რაც მასშტაბირებას აგრძელებს, დისკია: ყოველი დამატებითი ბაზა შეიძლება 10 GB-მდე იყოს, და ლოგებს, backup-ებსა და tempdb-ს ადგილი სჭირდება. RE:NODE-ზე SQL Server-ის ხაზი Express Starter-იდან (2 GB, 10 GB დისკი, 1 vCPU) Express Max-მდე (6 GB, 80 GB დისკი, 4 vCPU) გრძელდება, თვეში $6-დან; უფრო დიდი tier-ები მეტი ბაზისთვის ადგილსა და სრულ ოთხ ბირთვს ეხება და არა მეტ cache-ს.

მონაცემებთან ერთად ტრანზაქციის ლოგსაც ადევნე თვალი. Full recovery model-ში ლოგი იზრდება, სანამ ლოგის backup მას არ შეკვეცს, და რადგან ლოგის backup-ების ასაღებად Agent არ არის, full recovery-ში მყოფი ბაზა, რომლის backup-საც არავინ იღებს, ლოგს მანამ ზრდის, სანამ დისკი არ გაივსება. შეამოწმე, რომელ model-ს იყენებს შენი ბაზები:

SELECT name, recovery_model_desc FROM sys.databases;

თუ ლოგის backup-ებს არ იღებ, გამოიყენე SIMPLE. Recovery model-ები და ლოგის ზრდა ამ არჩევანს განმარტავს.

როცა Express საკმარისი არ არის#

Express-იდან გადადი, როცა ერთ-ერთი ეს სიმართლეა, და არა უფრო ადრე:

• ერთი ბაზა 10 GB-ს გადაცილებისკენ მიდის, და გასუფთავება, კომპრესია და დაყოფა რეალისტური არ არის. Standard edition ზომის ლიმიტს ოპერაციული სისტემის ლიმიტამდე ზრდის.
• Working set 1.4 GB-ზე ბევრად დიდია და შეგიძლია აჩვენო, რომ დისკიდან წაკითხვა არის შემაფერხებელი. Standard 128 GB-მდე buffer pool-ს უშვებს.
• SQL Server-ის შიგნით მაღალი ხელმისაწვდომობა გჭირდება - availability group-ები, failover კლასტერინგი, log shipping. არცერთი მათგანი Express-ში არ არსებობს.
• გჭირდება Agent-ზე დაფუძნებული დავალებები, Database Mail-ის alert-ები ან რეპლიკაცია publisher-ის როლში, და გარე გამგეგმავი მისაღები არ არის.

ჩვეული მიმართულებებია Standard edition სერვერზე, რომელსაც თავად ალიცენზირებ (თითო ბირთვზე ან სერვერი პლუს CAL-ები, მნიშვნელოვანი ხარჯი), Azure SQL Database ან Azure SQL Managed Instance, ან სხვა ძრავი. ახალი პროექტისთვის SQL Server-ზე დამოკიდებულების გარეშე PostgreSQL-ს edition-ის ლიმიტები საერთოდ არ აქვს; რომელი ბაზა გამოვიყენო მათ ამოცანების მიხედვით ადარებს. არსებული ბაზის უფრო მაღალ edition-ზე გადატანა backup და აღდგენაა: Express-ის .bak უცვლელად აღდგება იმავე ან უფრო ახალი ვერსიის Standard-ზე ან Enterprise-ზე. ბაზის მიგრაცია SQL Server ჰოსტინგზე საპირისპირო მიმართულებასა და ვერსიების წესებს განიხილავს.

რაც არ უნდა გააკეთო, არის Developer edition-ის production-ში გაშვება ლიმიტების ასარიდებლად. ის უფასოა და ყველა შესაძლებლობა აქვს, მაგრამ მისი ლიცენზია production-ში გამოყენებას კრძალავს.

FAQ#

უფასოა SQL Server Express კომერციული გამოყენებისთვის?

დიახ. Express ლიცენზირებულია production-ისა და კომერციული გამოყენებისთვის უფასოდ. ჰოსტს იმ სერვერისთვის უხდი, რომელზეც ის მუშაობს, და არა SQL Server-ის ლიცენზიისთვის.

10 GB ლიმიტი ტრანზაქციის ლოგსაც მოიცავს?

არა. მხოლოდ მონაცემთა ფაილები ითვლება. ლოგს შეუძლია 10 GB-ზე მეტად გაიზარდოს, დისკის ადგილით შეზღუდული, რის გამოც full recovery model-ში უმართავი ლოგი პატარა სერვერებზე რეალური რისკია.

შეიძლება ერთ Express ინსტანსზე ერთზე მეტი 10 GB ბაზა მქონდეს?

დიახ. ლიმიტი თითო ბაზაზეა. ერთმანეთთან დაუკავშირებელი მონაცემების ცალკე ბაზებად დაყოფა ნორმალური პრაქტიკაა და თითოეულს ზღვარს ქვემოთ ინარჩუნებს.

Express-ისთვის მეტი RAM-ის მიცემა მას უფრო სწრაფს გახდის?

გარკვეულ წერტილამდე. Buffer pool 1,410 MB-ზე ჩერდება, ამიტომ მეხსიერება იმაზე მეტი, რაც ამ ზღვარს, ოპერაციულ სისტემასა და ძრავის დანარჩენ ნაწილს სჭირდება, გამოუყენებელია. თუ cache უკვე ზღვარზეა და დისკიდან წაკითხვაა შემაფერხებელი, შემდეგი ნაბიჯი უკეთესი ინდექსები ან სხვა edition-ია და არა მეტი RAM.

შემიძლია Express-ის backup აღვადგინო Standard-ზე ან Azure SQL-ზე?

იმავე ან უფრო ახალი ვერსიის Standard-ზე ან Enterprise-ზე - დიახ, პირდაპირ. Azure SQL Database .bak ფაილებს არ აღადგენს; მასზე .bacpac ექსპორტით ან მიგრაციის ინსტრუმენტით გადადიხარ. Azure SQL Managed Instance კი native backup-ებს აღადგენს.

უჭერს SQL Server Express მხარს stored procedure-ებსა და trigger-ებს?

დიახ. მთელი T-SQL ხელმისაწვდომია, მათ შორის stored procedure-ები, ფუნქციები, trigger-ები, view-ები, CTE-ები და window ფუნქციები. ლიმიტები მოცულობასა და სერვერის რამდენიმე შესაძლებლობას ეხება და არა ენას.