დისტანციურ SQL Server-თან დაკავშირება SSMS-ით

SQL Server Management Studio-ს ჰოსტირებულ SQL Server-თან დასაკავშირებლად გახსენი Connect to Server და დააყენე ოთხი რამ: Server name არის ჰოსტი და პორტი, მძიმით გამოყოფილი (db.example.net,14330 - ორწერტილი არ იმუშავებს), Authentication არის SQL Server Authentication, Login და Password ის credential-ებია, რომლებიც მოგცეს (ახალ სერვერზე ხშირად sa), ხოლო შიფრაციაში დატოვე Mandatory და მონიშნე Trust server certificate, თუ სერვერს სანდო ორგანოს სერტიფიკატი არ აქვს. ეს თითქმის ყველა პირველ კავშირს ფარავს. პოსტის დანარჩენი ნაწილი თითოეულ ველს განმარტავს, ასევე ოფციებს, რომელთა შეცვლაც ღირს, რა გააკეთო შესვლის შემდეგ, და ზუსტ შეცდომის შეტყობინებებს ჩავარდნის ყოველი გზისთვის.

რა გჭირდება დაწყებამდე#

ოთხი ინფორმაცია და ერთი პროგრამა:

• ჰოსტი - ჰოსტის სახელი ან IP მისამართი.
• პორტი - SQL Server-ის ნაგულისხმევი პორტი 1433-ია, მაგრამ ჰოსტირებული სერვერები ხშირად სხვას იყენებს, რადგან ბევრი სერვერი ერთ მისამართს იზიარებს. გამოიყენე ის პორტი, რომელიც მოგცეს, და არა ნაგულისხმევი.
• Login - SQL login-ის სახელი. ახალ სერვერზე ეს ჩვეულებრივ sa-ა, ჩაშენებული სისტემური ადმინისტრატორი.
• პაროლი - ამ login-ისთვის.
• SSMS - SQL Server Management Studio, Microsoft-ის უფასო მართვის ინსტრუმენტი. ის მხოლოდ Windows-ზე მუშაობს.

SSMS-ის ბოლო რელიზებმა (ვერსია 20 და შემდეგი) შემოიტანა ქვემოთ აღწერილი შიფრაციის ოფციები. თუ შენი ასლი უფრო ძველია, განაახლე; ძველი ვერსიები იყენებს ძველ დრაივერს სხვა ნაგულისხმევებით და წლების შესწორებები აკლია. macOS-ზე ან Linux-ზე გამოიყენე Visual Studio Code Microsoft-ის MSSQL extension-ით, DBeaver, ან ბრძანების ხაზის sqlcmd - ამ პოსტის ყოველ ველს იქ ექვივალენტი აქვს. Azure Data Studio, რომელიც ადრე კროს-პლატფორმული პასუხი იყო, Microsoft-მა გააუქმა, ამიტომ მასში ახალ სამუშაოს ნუ დაიწყებ.

სანამ SSMS-ს დაადანაშაულებ, შეამოწმე, მისაწვდომია თუ არა პორტი შენი მანქანიდან. PowerShell-ში:

PS> Test-NetConnection db.example.net -Port 14330

TcpTestSucceeded : True ნიშნავს, რომ ქსელის გზა ღიაა, და ყველაფერი, რაც ამის შემდეგ ვარდება, SSMS-ის პარამეტრი ან credential-ია. False ნიშნავს, რომ firewall - შენი, შენი ქსელის ან სერვერის - გზაზე დგას, და SSMS-ში ვერაფერი გამოასწორებს. ზოგიერთი ოფისისა და სკოლის ქსელი გამავალ ტრაფიკს უჩვეულო პორტებზე ბლოკავს; ამის გამოსარიცხად სხვა კავშირიდან სცადე.

Connect to Server დიალოგი, ველი ველის მიხედვით#

მძიმე ყველაზე გავრცელებული შეცდომაა. SQL Server-ის ინსტრუმენტებმა host,port სინტაქსი თავდაპირველი კლიენტის ბიბლიოთეკებისგან მემკვიდრეობით მიიღო, და Microsoft-ის სტეკში ყველაფერი - SSMS, sqlcmd, ADO.NET connection string-ები, ODBC - მას იყენებს. დაწერე db.example.net:14330 და კლიენტი მთელ სტრიქონს ჰოსტის სახელად აღიქვამს, ვერ ხსნის მას ან named pipes-ს ცდის, და გაძლევს ქსელის შეცდომას, რომელიც ორწერტილზე არაფერს ამბობს. Backslash-იანი ფორმა, host\INSTANCE, არის named instance-ებისთვის, რომლებიც SQL Server Browser სერვისით მოიძებნება UDP 1434-ზე, რომელსაც ჰოსტირებული სერვერები არ ხსნის; ცხადი პორტით ის არასოდეს დაგჭირდება.

tcp: პრეფიქსი (tcp:db.example.net,14330) კლიენტს ეუბნება, გამოიყენოს TCP და სხვა არაფერი. ის არასავალდებულოა და კლიენტს აჩერებს, რომ რამის არასწორად კონფიგურირებისას ჯერ სხვა პროტოკოლები სცადოს, რაც შეცდომებს უფრო გასაგებს ხდის.

RE:NODE-ზე SQL Server-ის გეგმები ისეა მოწყობილი, რომ ეს დიალოგი საკმარისია: სერვერს საკუთარი sa პაროლი აქვს, და ბაზა შენთვის იქმნება და sa-ს ნაგულისხმევად ყენდება, ამიტომ SSMS პირდაპირ მასში იხსნება. სერვერის სახელი გეგმაზე ნაჩვენები ჰოსტი და პორტია, მძიმით.

შიფრაცია და Trust server certificate#

SSMS 20-მა ძველი "Encrypt connection" checkbox-ი შეცვალა Encryption პარამეტრით სამი მნიშვნელობით და გადავიდა დრაივერზე, რომელიც ნაგულისხმევად შიფრავს:

Mandatory-ით - რაც ნაგულისხმევია - კლიენტი სერვერის სერტიფიკატს ისე ამოწმებს, როგორც ბრაუზერი ვებსაიტისას: ის უნდა უკავშირდებოდეს ორგანოს, რომელსაც მანქანა ენდობა, და მისი სახელი უნდა ემთხვეოდეს სერვერის სახელს, რომელიც აკრიფე. SQL Server, რომელსაც სერტიფიკატი არ მისცეს, გაშვებისას self-signed სერტიფიკატს აგენერირებს, რომელსაც არცერთი მანქანა არ ენდობა, ამიტომ კავშირი ასე ვარდება:

A connection was successfully established with the server, but then an error occurredduring the login process. (provider: SSL Provider, error: 0 - The certificate chainwas issued by an authority that is not trusted.)

Trust server certificate-ის მონიშვნა კავშირს დაშიფრულს ტოვებს და შემოწმებას გამოტოვებს. ეს ნორმალური პარამეტრია ჰოსტირებული სერვერისთვის self-signed სერტიფიკატით, და შიფრაციის გამორთვაზე საგრძნობლად უკეთესია: შენი პაროლი და მონაცემები ინტერნეტს მაინც დაშიფრული კვეთს. რასაც კარგავ, არის დაცვა იმისგან, რომ ვინმემ კავშირი ჩაჭრას და საკუთარი სერტიფიკატი წარადგინოს, რისთვისაც მას შენსა და სერვერს შორის ქსელის გზაზე უნდა ეჯდეს.

თუ სერვერს აქვს სანდო ორგანოს სერტიფიკატი ისეთი სახელისთვის, როგორიცაა sql.example.com, დაუკავშირდი ამ სახელით და Trust server certificate მოუნიშნავი დატოვე, რომ სრული შემოწმება მიიღო. Host name in certificate, კავშირის თვისებებში, იმ შემთხვევას ფარავს, როცა ერთი სახელით უკავშირდები, სერტიფიკატს კი სხვა აწერია.

Strict რეჟიმი სერტიფიკატს ამოწმებს და self-signed მოწყობისთვის არ არის; სერვერთან, რომელიც self-signed სერტიფიკატს წარადგენს, გამოიყენე Mandatory Trust server certificate-ით.

ოფციები, რომელთა დაყენებაც Options-ში ღირს#

Options >> ღილაკი კიდევ სამ ჩანართს ხსნის. დისტანციური სერვერისთვის მნიშვნელოვანი:

• Connect to database (Connection Properties) - <default> login-ის ნაგულისხმევ ბაზას იყენებს. აქ ბაზის სახელის აკრეფა პირდაპირ მასში გახსნის. მისი master-ზე დაყენება ერთი კონკრეტული შეცდომისგან თავის დაღწევის გზაა, რომელიც ქვემოთ, პრობლემების მოგვარებაშია აღწერილი.
• Network protocol - <default> კარგია; დისტანციური ჰოსტისთვის ასეც და ისეც TCP/IP გამოიყენება.
• Connection time-out - გაზარდე, თუ ნელი ან შორეული კავშირით უერთდები და შესვლისას timeout-ებს ხედავ.
• Execution time-out - 0 ნიშნავს, რომ query-ებს კლიენტის მხრიდან timeout არასოდეს აქვს, რაც SSMS-ის ნაგულისხმევია და რაც მოვლის გრძელი სკრიპტებისთვის გინდა.
• Use custom color - ამ კავშირისთვის status bar-ს აფერადებს. Production სერვერებს წითელი მიეცი. არაფერი ჯდება და ბევრს შეუშალა ხელი, რომ სატესტო სკრიპტი არასწორ ფანჯარაში გაეშვა.

SSMS-ს შეუძლია კავშირები პაროლებით შენს Windows პროფილში შეინახოს. საკუთარ მანქანაზე მოსახერხებელია, საზიაროზე ცუდი იდეაა, და sa-სთვის შენახული პაროლი სერვერის სრული გასაღებია.

პირველი ნაბიჯები დაკავშირების შემდეგ#

გახსენი query ფანჯარა (Ctrl+N, ან New Query) და დაადასტურე, სად ხარ:

SELECT @@SERVERNAME AS server_name,       SERVERPROPERTY('Edition') AS edition,       SERVERPROPERTY('ProductVersion') AS version,       DB_NAME() AS current_database,       SUSER_SNAME() AS login_name;

ჰოსტირებულ Express სერვერზე ეს აჩვენებს Express Edition (64-bit)-ს, 16.0.x ვერსიის ნომერს SQL Server 2022-ისთვის და ბაზას, რომელშიც მოხვდი. Toolbar-ზე ბაზის ჩამოსაშლელი სია და USE [dbname]; ორივე ბაზას ცვლის.

შემდეგ, სანამ აპლიკაციის კოდს sa-ზე დაწერ, შექმენი აპლიკაციისთვის ცალკე login და user მხოლოდ საჭირო უფლებებით. sa-ს სერვერზე ყველა ბაზის წაშლა შეუძლია, და connection string, რომელიც მას შეიცავს, კონფიგურაციის ფაილებში, გარემოს ცვლადებსა და დეველოპერების ლეპტოპებში ცხოვრობს. SQL Server-ის login-ები, user-ები და როლები ზუსტ სკრიპტს შეიცავს. როცა ის არსებობს, sa გამოიყენე SSMS-იდან ადმინისტრირებისთვის და სხვა არაფრისთვის.

Object Explorer, მარცხნივ, აჩვენებს ბაზებს, ცხრილებს, view-ებსა და უსაფრთხოების principal-ებს. ცხრილზე მარჯვენა დაწკაპუნება გაძლევს Select Top 1000 Rows-სა და Edit Top 200 Rows-ს, რომლებიც დასათვალიერებლად კარგია და მასობრივი ცვლილებებისთვის ცუდი - ყველაფრისთვის, რაც რამდენიმე row-ზე მეტს ეხება, გამოიყენე T-SQL, ტრანზაქციის შიგნით, რომლის rollback-იც შეგიძლია:

BEGIN TRANSACTION;UPDATE dbo.Customers SET Country = 'GB' WHERE Country = 'UK';-- შეამოწმე row-ების რაოდენობა Messages ჩანართში, შემდეგ:COMMIT;   -- or ROLLBACK;

მონაცემების შეტანა და გატანა SSMS-ით#

SSMS-ს ამისთვის რამდენიმე ინსტრუმენტი აქვს, და სწორი იმაზეა დამოკიდებული, სად მიდის მონაცემები:

• Generate Scripts (ბაზაზე მარჯვენა დაწკაპუნება, Tasks) სქემას და, სურვილისამებრ, მონაცემებს T-SQL-ად წერს. კარგია პატარა ბაზებისთვის და ვერსიებს შორის გადასატანად, რადგან სკრიპტი ნებისმიერ ვერსიაზე გაეშვება, რომელიც მის სინტაქსს უჭერს მხარს.
• Import Flat File CSV-ს ახალ ცხრილში ტვირთავს, სვეტების ტიპების წინასწარი ხედით. სწრაფია ერთჯერადი იმპორტისთვის.
• Export Data-tier Application ქმნის .bacpac-ს, სქემისა და მონაცემების პაკეტს, რომელიც შეიძლება სხვა SQL Server-ში ან Azure SQL Database-ში შემოიტანო.
• Back Up and Restore native .bak ფაილებთან მუშაობს, მაგრამ ფაილის ბილიკი ამ დიალოგებში სერვერზე არსებული ბილიკია და არა შენს PC-ზე. ადგილობრივად არსებული .bak-ის აღსადგენად ის ჯერ სერვერზე უნდა აიტვირთოს, დირექტორიაში, რომლის წაკითხვაც SQL Server-ის პროცესს შეუძლია.

ყველაფრისთვის, რაც დიდია ან განმეორებადი, ბრძანების ხაზის ინსტრუმენტები wizard-ებზე უკეთესია: sqlcmd სკრიპტებისთვის და bcp მასობრივი კოპირებისთვის, განხილული sqlcmd და bcp-ში. მთელი ბაზის სხვა ჰოსტიდან გადატანა ცალკე პროცედურაა, ვერსიების წესებით, აღწერილი სტატიაში ბაზის მიგრაცია SQL Server ჰოსტინგზე.

კავშირის შეცდომების მოგვარება#

`A network-related or instance-specific error occurred while establishing a connection to SQL Server. ... (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)` - კლიენტმა სერვერს TCP-ით ვერასოდეს მიაღწია. შეამოწმე, ორწერტილი ხომ არ წერია მძიმის ნაცვლად, პორტი ხომ არ არის არასწორი, ან firewall ხომ არ ბლოკავს. ზემოთ მოცემული Test-NetConnection გეტყვის, რომელია.

`(provider: TCP Provider, error: 0 - No such host is known.)` - ჰოსტის სახელი ვერ იხსნება. ბეჭდვის შეცდომა, ან DNS ჩანაწერი, რომელიც ჯერ არ არსებობს.

`(provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)` - გამოიყენე host\INSTANCE, და კლიენტი SQL Server Browser სერვისს ეძებს. სამაგიეროდ გამოიყენე host,port.

`The certificate chain was issued by an authority that is not trusted.` - შიფრაცია Mandatory-ია და სერტიფიკატი self-signed. მონიშნე Trust server certificate.

`The target principal name is incorrect.` - სერტიფიკატი ვალიდურია, მაგრამ სხვა სახელზეა გაცემული, ვიდრე ის, რაც აკრიფე. დაუკავშირდი სერტიფიკატზე მითითებული სახელით, დააყენე Host name in certificate, ან ენდე სერტიფიკატს.

`Login failed for user 'sa'. (Microsoft SQL Server, Error: 18456)` - არასწორი პაროლი, არასწორი login-ის სახელი, ან login გამორთულია. შეტყობინება განზრახ არ ამბობს, რომელი; სერვერის შეცდომების ლოგი state ნომერს იწერს, რომელიც ამას ამბობს. პაროლი ხელახლა აკრიფე და ნუ ჩასვამ, რადგან ჩასმულ პაროლებს ხშირად ბოლოში ჰარი მოსდევს.

`Cannot open user default database. Login failed. (Error: 4064)` - login-ის ნაგულისხმევი ბაზა წაიშალა, გადაერქვა ან offline-ია. ეს მათ იჭერს, ვინც ალაგებს: სერვერზე, სადაც sa-ს ნაგულისხმევი შენთვის შექმნილი ბაზაა, ამ ბაზის წაშლა ან გადარქმევა ნიშნავს, რომ sa ჩვეულებრივი გზით ვეღარ შევა. გამოასწორე ასე: გახსენი Options >> Connection Properties, Connect to database-ში ჩაწერე master, დაუკავშირდი და შემდეგ გაუშვი:

ALTER LOGIN [sa] WITH DEFAULT_DATABASE = [master];

კავშირი მუშაობს, შემდეგ უმოქმედობის შემდეგ წყდება. ქსელის გზაზე რაღაც უმოქმედო TCP კავშირებს ხურავს. თავიდან დაუკავშირდი, და ხანგრძლივი სამუშაო სკრიპტებში შეინახე და არა უმოქმედო ფანჯრებში.

FAQ#

რატომ სჭირდება SSMS-ს მძიმე ორწერტილის ნაცვლად პორტის წინ?

იმიტომ, რომ SQL Server-ის კლიენტის ბიბლიოთეკები სერვერის სახელს host,port-ად განსაზღვრავს, და ყოველთვის ასე იყო. ორწერტილიანი ფორმა, რომელსაც სხვა ბაზების უმეტესობა და URL-ები იყენებს, ჰოსტის სახელის ნაწილად იკითხება. გამონაკლისი JDBC-ა: მის URL-ებში ორწერტილია.

უსაფრთხოა Trust server certificate-ის მონიშვნა?

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

შემიძლია SSMS Mac-ზე გამოვიყენო?

არა, SSMS მხოლოდ Windows-ისთვისაა. გამოიყენე Visual Studio Code MSSQL extension-ით, DBeaver ან sqlcmd. თითოეულში იგივე სერვერის სახელი, login და შიფრაციის პარამეტრები მოქმედებს.

sa login ჩემი აპლიკაციისთვის გამოვიყენო?

არა. sa გამოიყენე SSMS-იდან ადმინისტრირებისთვის, და თითოეული აპლიკაციისთვის შექმენი ცალკე login მხოლოდ საჭირო უფლებებით. თუ აპლიკაციის credential-ები გაჟონავს, ზიანი შემოიფარგლება იმით, რისი გაკეთებაც ამ login-ს შეუძლია.

რატომ ვუკავშირდები სახლიდან, მაგრამ სამსახურიდან არა?

შენი სამსახურის ქსელი სერვერის პორტზე გამავალ კავშირებს ბლოკავს. დასადასტურებლად ორივე ადგილიდან გაუშვი Test-NetConnection, შემდეგ ან სთხოვე, რომ პორტი დაუშვან, ან სხვა ადგილიდან დაუკავშირდი.