SQL Server-ის ბაზის ახალ ჰოსტზე გადატანის საუკეთესო გზა native backup და აღდგენაა: BACKUP DATABASE ... WITH COPY_ONLY, CHECKSUM ძველ სერვერზე, .bak-ის კოპირება, RESTORE DATABASE ... WITH MOVE ახალზე. ის ზუსტია, სწრაფია და ყველაფერს ინარჩუნებს, რაც ბაზის შიგნითაა - სქემას, მონაცემებს, user-ებს, უფლებებს, სტატისტიკას. ის მხოლოდ ზემოთ მუშაობს, იმავე ან უფრო ძველი SQL Server ვერსიიდან, და მხოლოდ მაშინ, თუ ბაზა სამიზნე ედიციაში ეტევა. როცა ეს არ მოქმედებს - უფრო ძველ ვერსიაზე გადასვლისას, Azure SQL Database-იდან მოსვლისას ან MySQL-იდან თუ PostgreSQL-იდან გადმოსვლისას - ალტერნატივებია BACPAC, გენერირებული სკრიპტები ან სქემის კონვერტაცია პლუს მონაცემების ჩატვირთვა. ეს გზამკვლევი განიხილავს, როგორ აირჩიო, რა შემოწმებები გაუშვა დაწყებამდე, თითოეულ მეთოდს რიგრიგობით და გაწმენდას, რომელიც ყოველ მიგრაციას შემდეგ სჭირდება.
მეთოდის არჩევა#
| მეთოდი | როდის მუშაობს | სიჩქარე | რას ინარჩუნებს |
|---|---|---|---|
Backup და აღდგენა (.bak) | წყარო SQL Server-ია, სამიზნის იგივე ან უფრო ძველი ვერსიის | ყველაზე სწრაფი | ყველაფერს ბაზაში |
BACPAC (SqlPackage) | ნებისმიერი SQL Server ან Azure SQL Database, ნებისმიერი მიმართულებით | ნელია დიდ ზომაზე | სქემას და მონაცემებს; არა ისტორიას ან სტატისტიკას |
| Generate Scripts (SSMS) | პატარა ბაზები, ნებისმიერი მიმართულებით | ნელი, დიდი ფაილები | სქემას, სურვილისამებრ მონაცემებს INSERT-ებად |
bcp თითო ცხრილზე | სქემა სამიზნეზე უკვე შექმნილია | სწრაფი | მხოლოდ მონაცემებს |
| SSMA ან ხელით კონვერტაცია | წყარო MySQL, Oracle, Access, Db2 ან სხვა ძრავია | განსხვავდება | რასაც გადააკონვერტირებ |
გადაწყვეტილებას ძირითადად ორი კითხვა იღებს. წყარო SQL Server სამიზნის იგივე ან უფრო ძველი ვერსიისაა? მაშინ backup და აღდგენა. უფრო ახალია, ან Azure SQL Database, რომელსაც .bak ფაილის შექმნა საერთოდ არ შეუძლია? მაშინ BACPAC. გენერირებული სკრიპტები პატარა ბაზებისთვისაა, სადაც გინდა წაიკითხო ან დაარედაქტირო ის, რაც გადადის, კონვერტაციის ინსტრუმენტები კი სხვა ძრავის დასატოვებლად.
შემოწმებები, სანამ რამეს გადაიტან#
წყაროზე ხუთი წუთის query-ები შუაღამისას ჩავარდნილ აღდგენას გადაგარჩენს.
ვერსია. წყაროზე გაუშვი SELECT @@VERSION;. backup აღდგება მხოლოდ იმავე ან უფრო ახალ major ვერსიაზე: 2022 არის ვერსია 16, 2019 - 15, 2017 - 14, 2016 - 13. SQL Server 2022 აღადგენს backup-ებს SQL Server 2008-დან მოყოლებული; ბაზას, რომელიც ჯერ კიდევ 2005-ზე ან უფრო ძველზეა, შუალედური გადასვლა სჭირდება ვერსიით, რომელიც მას მიიღებს.
ზომა. თუ სამიზნე Express-ია, თითოეული ბაზა მონაცემთა ფაილების 10 GB-ით არის შეზღუდული (log არ ითვლება). შეამოწმე, რეალურად რამდენს იყენებ, და არა გამოყოფილი ფაილის ზომა:
SELECT name, type_desc, size / 128.0 AS allocated_mb, FILEPROPERTY(name, 'SpaceUsed') / 128.0 AS used_mbFROM sys.database_files;ბაზა 14 GB გამოყოფილით და 6 GB გამოყენებულით Express-ზე კარგად აღდგება მხოლოდ მაშინ, თუ მონაცემთა ფაილები ჯერ 10 GB-ზე ქვემოთ შეიკუმშება, რადგან აღდგენა ფაილებს მათი თავდაპირველი ზომით ქმნის. საბოლოო backup-მდე მონაცემთა ფაილი წყაროზე (ან აღდგენილ ასლზე) შეკუმშე, შემდეგ ინდექსები ხელახლა ააგე და გაითვალისწინე, რომ შეკუმშვა ინდექსებს ძლიერ აფრაგმენტებს. თუ მართლა 10 GB-ზე მეტს იყენებ, ჯერ ძველი მონაცემები დაარქივე ან აირჩიე ედიცია ზღვრის გარეშე - SQL Server Express ჰოსტინგი განიხილავს, სად გადის ეს ზღვარი.
ედიციის ფუნქციები. ზოგიერთი ფუნქცია ბაზას ედიციაზე აბამს. ეს view ჩამოთვლის გამოყენებულს:
SELECT feature_name FROM sys.dm_db_persisted_sku_features;SQL Server 2016 Service Pack 1-დან პროგრამირებადობის ფუნქციების უმეტესობა - partitioning, columnstore, მონაცემების შეკუმშვა, in-memory OLTP - ყველა ედიციაშია ხელმისაწვდომი, ამიტომ თანამედროვე წყაროზე ეს ჩვეულებრივ არაფერს აბრუნებს. თუ ის Transparent Data Encryption-ს ჩამოთვლის, ეს ბაზა Express-ზე არ აღდგება; ჯერ წყაროზე გაშიფრე.
დამოკიდებულებები ბაზის გარეთ. ჩამოწერე, რა ცხოვრობს ძველ სერვერზე და არა ბაზაში: SQL Server Agent-ის job-ები, linked server-ები, login-ები, Database Mail-ის პროფილები, სერვერის დონის trigger-ები და ნებისმიერი კოდი, რომელიც სხვა ბაზებს სამნაწილიანი სახელით მიმართავს (otherdb.dbo.Table). არცერთი მათგანი backup-თან ერთად არ მოგზაურობს. Agent-ის job-ები განსაკუთრებულ ყურადღებას იმსახურებს, როცა სამიზნე Express-ია, რომელსაც Agent არ აქვს - თითოეული job სადღაც სხვაგან დაგეგმილ sqlcmd გამოძახებად იქცევა, როგორც sqlcmd და bcp აჩვენებს.
მეთოდი 1: backup და აღდგენა#
წყაროზე აიღე copy-only backup, რომ მისი არსებული backup-ების ჯაჭვი არ დაარღვიო:
BACKUP DATABASE [shop]TO DISK = N'D:\Backups\shop-migrate.bak'WITH COPY_ONLY, CHECKSUM, INIT, STATS = 10;RESTORE VERIFYONLY FROM DISK = N'D:\Backups\shop-migrate.bak' WITH CHECKSUM;დააკოპირე ფაილი ახალ სერვერზე, დირექტორიაში, რომელსაც SQL Server-ის პროცესი კითხულობს. RESTORE გზას სერვერზე ხსნის და არა შენს სამუშაო მანქანაზე, ამიტომ ფაილის ატვირთვა ცალკე ნაბიჯია: SFTP, ჰოსტის ფაილ მენეჯერი ან რასაც ჰოსტი გთავაზობს. RE:NODE-ზე ყოველ სერვერს აქვს SFTP და ფაილ მენეჯერი; თუ არ ხარ დარწმუნებული, რომელ საქაღალდეს კითხულობს ძრავი, დიდი ფაილის ატვირთვამდე support-ს ჰკითხე.
შემდეგ წაიკითხე ლოგიკური ფაილის სახელები და აღადგინე, თითოეული ფაილი სამიზნის მონაცემთა დირექტორიაში გადატანით. Windows-ის წყაროს backup-ში Windows-ის გზები აქვს ჩაშენებული, და Linux-ის სამიზნეზე ყველა მათგანი უნდა გადაიტანო:
RESTORE FILELISTONLY FROM DISK = N'/var/opt/mssql/data/shop-migrate.bak';RESTORE DATABASE [shop]FROM DISK = N'/var/opt/mssql/data/shop-migrate.bak'WITH MOVE N'shop' TO N'/var/opt/mssql/data/shop.mdf', MOVE N'shop_log' TO N'/var/opt/mssql/data/shop_log.ldf', RECOVERY, CHECKSUM, STATS = 10;SELECT SERVERPROPERTY('InstanceDefaultDataPath'); სწორ დირექტორიას გაძლევს, თუ ის არ იცი. აღდგენის შემდეგ backup ფაილის სერვერიდან წაშლა შეიძლება - შეზღუდული დისკის გეგმაზე 9 GB-იანი .bak 9 GB-იანი ბაზის გვერდით მისი შევსების ყველაზე სწრაფი გზაა. SQL Server backup და აღდგენა აღდგენის ოფციებსა და შეცდომებს უფრო სიღრმისეულად განიხილავს.
ჰოსტინგის სერვერზე შეიძლება შენთვის უკვე იყოს შექმნილი ბაზა. შეგიძლია მასზე REPLACE-ით აღადგინო, ან შენი თავდაპირველი სახელით აღადგინო და ყველაფერი მასზე მიუთითო. თუ შენს sa login-ს წინასწარ შექმნილი ბაზა აქვს ნაგულისხმევად და სხვა სახელით აღადგენ, ნაგულისხმევი შეცვალე, რომ ინსტრუმენტებმა სწორი გახსნან:
ALTER LOGIN [sa] WITH DEFAULT_DATABASE = [shop];მეთოდი 2: BACPAC SqlPackage-ით#
BACPAC არის zip ფაილი, რომელიც ბაზის სქემას მოდელად ინახავს, პლუს ყოველი ცხრილის მონაცემებს bulk-copy ფორმატში. ის იქმნება წყაროსთან კლიენტად დაკავშირებით, ამიტომ არცერთ სერვერზე ფაილურ წვდომას არ საჭიროებს, მუშაობს Azure SQL Database-იდან და შეუძლია ბაზის უფრო ძველ ვერსიაზე გადატანა, თუ ის არ იყენებს ფუნქციებს, რომლებიც ძველ ვერსიას აკლია.
$ sqlpackage /Action:Export \ /SourceConnectionString:"Server=old.example.net,1433;Database=shop;User Id=sa;Password=...;TrustServerCertificate=True" \ /TargetFile:shop.bacpac$ sqlpackage /Action:Import \ /SourceFile:shop.bacpac \ /TargetConnectionString:"Server=db.example.net,14330;Database=shop;User Id=sa;Password=...;TrustServerCertificate=True"იმპორტი ბაზას ქმნის, ან ავსებს არსებულს, რომელიც სრულიად ცარიელია. SSMS-ში იგივე ოპერაციები ბაზის Tasks მენიუშია როგორც Export Data-tier Application, და Databases კვანძის ქვეშ როგორც Import Data-tier Application.
კომპრომისები რეალურია:
- თანმიმდევრულობა. ექსპორტი ცხრილებს ერთმანეთის მიყოლებით კითხულობს, ერთიანი snapshot-ის გარეშე. თუ ექსპორტის დროს ჩაწერები ხდება, BACPAC შეიძლება შეიცავდეს შეკვეთას მისი ხაზების გარეშე. გააჩერე აპლიკაცია, ან ექსპორტი backup-ის აღდგენილი ასლიდან გააკეთე.
- სიჩქარე. ის native backup-სა და აღდგენაზე რამდენჯერმე ნელია, იმპორტი კი ყოველ ინდექსს ხელახლა აგებს. რამდენიმე გიგაბაიტისთვის ნორმალურია, ათეულებისთვის - დამღლელი.
- ვალიდაცია. ექსპორტი ჯერ სქემას ამოწმებს და უარს ამბობს ბაზებზე, რომელთა წარმოდგენაც არ შეუძლია - ყველაზე ხშირად სხვა ბაზებზე მიმართვების ან ობიექტების გამო, რომლებიც აღარ კომპილირდება. შეცდომა ობიექტებს ასახელებს; გაასწორე ან წაშალე ისინი და თავიდან გაუშვი.
- რა არ გადადის. სტატისტიკა, Query Store-ის მონაცემები, transaction log და backup-ების ისტორია არ მოგზაურობს. Login-ებიც არა, მაგრამ contained user-ები და ბაზის user-ები - კი.
SqlPackage იმავე დაშიფვრის ნაგულისხმევებით უკავშირდება, რაც Microsoft-ის სხვა თანამედროვე დრაივერები, ამიტომ self-signed სერტიფიკატიან სერვერს connection string-ში TrustServerCertificate=True სჭირდება, როგორც ზემოთ. SQL Server-ის connection string-ები დაშიფვრის საკვანძო სიტყვებს განიხილავს.
მეთოდი 3: გენერირებული სკრიპტები და bcp#
პატარა ბაზისთვის SSMS-ს შეუძლია მთელი ბაზა T-SQL-ად ჩაწეროს: მარჯვენა ღილაკი ბაზაზე, Tasks, Generate Scripts. აირჩიე ობიექტები, შემდეგ Advanced-ში "Types of data to script" დააყენე "Schema and data"-ზე, "Script for Server Version" კი სამიზნის ვერსიაზე. შედეგი არის ერთი .sql ფაილი CREATE ინსტრუქციებით, რომლებსაც INSERT-ები მოჰყვება.
ის იკითხება, რედაქტირებადია და ვერსიისგან დამოუკიდებელია, რაც მას სწორ ინსტრუმენტად აქცევს რამდენიმე ასეული მეგაბაიტის ბაზისთვის, რომლის გზაში მოწესრიგებაც გინდა. ის არასწორი ინსტრუმენტია ყველაფრისთვის, რაც დიდია: სკრიპტი მილიონობით ერთ-row-იანი INSERT ინსტრუქციით ნელა ეშვება და SSMS-ს მისი გახსნაც კი უჭირს. დიდი სკრიპტები sqlcmd -i-ით გაუშვი და არა query ფანჯარაში.
უფრო დიდი ბაზებისთვის ორივე შეუთავსე: დააგენერირე მხოლოდ სქემის სკრიპტი, გაუშვი ის სამიზნეზე, შემდეგ კი მონაცემები ცხრილ-ცხრილ გადაიტანე bcp-ით native ფორმატში, რაც სწრაფი და ზუსტია. მშობელი ცხრილები შვილობილებზე ადრე ჩატვირთე, ან ჩატვირთვისას foreign key-ები გამორთე და შემდეგ WITH CHECK-ით ხელახლა ჩართე, რომ ისევ trusted იყოს.
MySQL-იდან ან PostgreSQL-იდან გადმოსვლა#
სხვა ძრავიდან გადმოსვლა კონვერტაციაა და არა კოპირება. MySQL-ის, Oracle-ის, Access-ის, Db2-ისა და SAP ASE-სთვის Microsoft-ის უფასო SQL Server Migration Assistant (SSMA) სქემას აკონვერტირებს, აღნიშნავს, რისი კონვერტაციაც ვერ შეძლო, და მონაცემებს აკოპირებს. PostgreSQL-ისთვის SSMA არ არსებობს; იქ სქემას ხელით ან შენი framework-ის მიგრაციებით აკონვერტირებ, შემდეგ კი მონაცემებს CSV-ით და bcp-ით ტვირთავ, ან პატარა სკრიპტით, რომელიც ერთი კავშირიდან კითხულობს და მეორეში bulk-copy-ით წერს.
ტიპების შესაბამისობა ძირითადად მექანიკურია:
| MySQL / PostgreSQL | SQL Server |
|---|---|
AUTO_INCREMENT / SERIAL, IDENTITY | int IDENTITY(1,1) |
BOOLEAN, TINYINT(1) | bit |
TEXT, LONGTEXT / text | nvarchar(max) |
VARCHAR(n) utf8mb4-ით / varchar(n) | nvarchar(n), ან varchar(n) UTF-8 collation-ით |
DATETIME / timestamp | datetime2 |
timestamptz | datetimeoffset |
uuid | uniqueidentifier |
JSON / jsonb | nvarchar(max) ISJSON check constraint-ით |
ENUM(...) | CHECK constraint ან lookup ცხრილი |
ტექსტური ტიპები ყველაზე მეტ ფიქრს იმსახურებს, რადგან MySQL და PostgreSQL ბოლომდე UTF-8-ია, SQL Server-ის varchar კი არა, თუ სვეტი UTF-8 collation-ს არ იყენებს. SQL Server-ის collation-ები და Unicode ამ არჩევანს ხსნის. თავად SQL-საც სჭირდება მუშაობა: LIMIT ხდება TOP ან OFFSET ... FETCH, backtick-ისა და ორმაგი ბრჭყალების იდენტიფიკატორები კვადრატულ ფრჩხილებად იქცევა, RETURNING ხდება OUTPUT, upsert-ები კი - MERGE ან ჯერ update და შემდეგ insert. T-SQL-ის საფუძვლები აპლიკაციის დეველოპერებისთვის აგროვებს განსხვავებებს, რომლებიც გკბენს. თუ აპლიკაცია ORM-ს იყენებს, მისი provider-ის შეცვლა და სქემის მიგრაციებიდან გენერირება ჩვეულებრივ უფრო სწრაფია, ვიდრე DDL-ის ხელით კონვერტაცია.
გადართვა მცირე downtime-ით#
პატარა ბაზისთვის უმარტივესი გადართვა გულწრფელია: აპლიკაცია maintenance რეჟიმში გადაიყვანე, აიღე საბოლოო backup, აღადგინე, შეცვალე connection string და აპლიკაცია უკან დააბრუნე. 5 GB-იანი ბაზისთვის ნორმალურ არხებზე ეს წუთების ფანჯარაა.
როცა ეს ზედმეტად დიდხანს გრძელდება, გამოიყენე full backup პლუს differential. full backup წინასწარ აღადგინე recovery-ის გარეშე, რომ შემდეგს დაელოდოს:
-- Days before: restore the full backup, leave it waitingRESTORE DATABASE [shop] FROM DISK = N'/var/opt/mssql/data/shop-full.bak'WITH MOVE N'shop' TO N'/var/opt/mssql/data/shop.mdf', MOVE N'shop_log' TO N'/var/opt/mssql/data/shop_log.ldf', NORECOVERY;-- At cutover: stop writes, take a differential on the source, thenRESTORE DATABASE [shop] FROM DISK = N'/var/opt/mssql/data/shop-diff.bak'WITH RECOVERY;differential მხოლოდ იმას შეიცავს, რაც full backup-ის შემდეგ შეიცვალა, ამიტომ downtime არის მისი აღების, კოპირებისა და გამოყენების დრო. გაითვალისწინე, რომ ამისთვის წყაროზე full backup COPY_ONLY არ უნდა იყოს, რადგან differential ყოველთვის ბოლო ჩვეულებრივ full backup-ს ეფუძნება. თუ წყარო full recovery model-შია, log backup-ებს შეუძლიათ ეს ხარვეზი კიდევ უფრო შეამცირონ. ნებისმიერ შემთხვევაში, ნამდვილ ღამემდე მთელი თანმიმდევრობა ერთხელ გაიარე დროებით ბაზაზე. მიგრაციები downtime-ის გარეშე აპლიკაციის მხარეს განიხილავს: სქემის ცვლილებებს, რომლებთანაც კოდის ორივე ვერსიას შეუძლია იცხოვროს.
აღდგენის შემდეგ: გაწმენდის სია#
ყოველ მიგრირებულ ბაზას ერთი და იგივე რამდენიმე რამ სჭირდება, სანამ აპლიკაცია მასზე მიუთითებს:
- ობოლი user-ების გასწორება. SQL login-ებს ახალ სერვერზე ახალი SID-ები აქვს, ამიტომ აღდგენილი user-ები მათ არ ემთხვევა. შექმენი თითოეული login-ი, შემდეგ
ALTER USER [app] WITH LOGIN = [app];. login-ების პაროლებითა და SID-ებით ხელუხლებლად გადასატანად Microsoft-ისsp_help_revloginსკრიპტი წყაროზეCREATE LOGINინსტრუქციებს აგენერირებს. SQL Server-ის login-ები, user-ები და როლები ამ მოდელს ხსნის. - Compatibility level-ის შემოწმება. აღდგენილი ბაზა ინარჩუნებს დონეს, რომელიც ჰქონდა, და ეს 2022 სერვერზე შეიძლება იყოს 110 ან 130. ჯერ აპლიკაცია ამ დონეზე გატესტე, შემდეგ აწიე:
ALTER DATABASE [shop] SET COMPATIBILITY_LEVEL = 160;. ჩართული Query Store-ით შეგიძლია plan-ები შეადარო ცვლილებამდე და შემდეგ და ნებისმიერ query-ს, რომელიც გაუარესდა, ძველი plan იძულებით მიუჩინო; SQL Server Query Store და ნელი query-ები აჩვენებს, როგორ. - სტატისტიკის განახლება.
EXEC sp_updatestats;აღდგენილ ბაზაში, რომ optimiser-ი არ მუშაობდეს სხვა აპარატურაზე და სხვა ვერსიის estimator-ით შეგროვებული მონაცემებით. - მთლიანობის შემოწმება.
DBCC CHECKDB WITH NO_INFOMSGS;ერთხელ, რომ ცნობილი ჯანმრთელი ბაზით დაიწყო. - გვერდების ვერიფიკაციის დაყენება. ბაზები, რომლებმაც სიცოცხლე ძალიან ძველ ვერსიებზე დაიწყეს, შეიძლება ჯერ კიდევ
TORN_PAGE_DETECTION-ს იყენებდნენ.ALTER DATABASE [shop] SET PAGE_VERIFY CHECKSUM;თანამედროვე პარამეტრია. - Recovery model-ის შემოწმება და log-ის ზომისაც, რომელიც შეიძლება წყაროდან ზედმეტად დიდი ჩამოვიდა.
- Connection string-ების განახლება: ახალი ჰოსტი, პორტი მძიმის შემდეგ, SQL authentication და დაშიფვრის პარამეტრები.
FAQ#
შემიძლია SQL Server 2022-ის backup-ის აღდგენა SQL Server 2019-ზე?
არა. backup-ები მხოლოდ იმავე ან უფრო ახალ ვერსიაზე აღდგება, და ამას არცერთი ოფცია ან trace flag არ ცვლის. ამის ნაცვლად BACPAC-ის ექსპორტი გააკეთე, ან სქემის სკრიპტი დააგენერირე და მონაცემები bcp-ით გადაიტანე, მას შემდეგ რაც შეამოწმებ, რომ ბაზა არაფერს იყენებს, რაც 2019-ს აკლია.
როგორ გადავიტანო Azure SQL Database-იდან ჰოსტინგის SQL Server-ზე?
Azure SQL Database-იდან BACPAC-ის ექსპორტი გააკეთე, პორტალით ან SqlPackage-ით, და სამიზნეზე იმპორტი. Azure SQL Database-ს native .bak ფაილის შექმნა არ შეუძლია, ამიტომ backup და აღდგენა მისგან ხელმისაწვდომი არ არის.
ჩემი ბაზა 12 GB-ია. შეუძლია SQL Server Express-ზე მუშაობა?
ასე, როგორც არის - არა. Express თითოეულ ბაზაში მონაცემებს 10 GB-ით ზღუდავს. შეამოწმე, რეალურად რამდენია გამოყენებული და არა გამოყოფილი, დაარქივე ან წაშალე ძველი მონაცემები და backup-მდე მონაცემთა ფაილი ზღვარს ქვემოთ შეკუმშე. თუ მონაცემები მართლა 10 GB-ს აჭარბებს, ფასიანი ედიცია გჭირდება.
მჭირდება transaction log ფაილის გადატანა?
მას WITH MOVE-ით გადაიტან, მონაცემთა ფაილის მსგავსად, მაგრამ მისი შიგთავსი ნაკლებად მნიშვნელოვანია: აღდგენა ბაზას აღადგენს და log იქიდან თავიდან იწყება. თუ წყაროს log უზარმაზარი იყო, აღდგენის შემდეგ ერთხელ შეკუმშე და გონივრული ზომა დააყენე, ძველი გაბერილობის გადმოტანის ნაცვლად.
ჩემი stored procedure-ები და view-ები გადმოვა?
დიახ, backup-ითა და აღდგენით, BACPAC-ით ან გენერირებული სკრიპტებით - ისინი ბაზის ნაწილია. რაც არ გადმოდის, ეს ყველაფერია, რაც სერვერის დონეზე ინახება: login-ები, Agent-ის job-ები, linked server-ები და სერვერის trigger-ები. ჩამოწერე ისინი დაწყებამდე.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.