연결하다 Azure SQL 엑셀, 구글 시트, AI 및 REST로

에이전트가 연결될 때 Azure가 보는 내용

Azure SQL은 누가 해당 서비스에 접근할 수 있는지에 대한 자체적인 기준이 있는 공유 서비스이므로, 어떤 데이터가 전달되는지 정확하게 정의하는 것이 중요합니다.

• 로그인 시도 전에 TCP를 통해 연결 가능성을 테스트하므로, 잘못된 서버 이름이나 차단된 경로는 Azure에 로그인 실패로 보고되는 대신 네트워크 문제로 처리됩니다.
• 연결 풀링이 비활성화되었습니다. 쿼리 간에 데이터베이스에 유휴 세션이 누적되지 않습니다. 서버리스 환경에서 이는 일시 정지 상태를 유지하는 것과 계속 활성화된 상태를 유지하는 것의 차이를 의미합니다.
• Azure 방화벽 자체의 거부는 그 이유를 정확히 인식하므로, 사용자의 주소를 알지 못하는 서버는 일반적인 오류가 아닌 네트워크 차단을 보고합니다.
• Azure SQL에 대한 모든 연결은 암호화됩니다. Azure는 TLS를 요구하고 그 이하의 프로토콜은 거부하기 때문입니다. 이러한 보장은 Azure 자체의 보증이며, 에이전트가 Azure를 대신하여 협상하는 것이 아닙니다.

서버리스, 그리고 일시 정지 후 첫 번째 쿼리

이는 마주치기 전에 알아두면 좋을 한 가지 까다로운 부분인데, 증상이 마치 연결이 끊어진 것처럼 보이지만 실제로는 그렇지 않기 때문입니다.

• 서버리스 데이터베이스는 유휴 상태일 때 자동으로 일시 중지되며, 다시 활성화하려면 연결 시도에 소요되는 시간이 필요합니다.
• 에이전트는 연결하는 데 30초, 쿼리 응답이 시작되는 데 35초가 걸립니다. 콜드 웨이크의 경우 이 시간을 초과할 수 있습니다.
• 자동 재시도 기능이 없으므로, 솔직히 말씀드리면 긴 대기 시간 후 첫 번째 쿼리는 시간 초과로 인해 두 번째 실행이 필요할 수 있습니다. 그 이후의 모든 작업은 정상적으로 진행됩니다.
• 일시 중지된 데이터베이스는 누락된 것으로 보고되는 대신 일시 중지된 것으로 인식되므로 실제로 발생한 상황을 알려주는 메시지가 표시됩니다.

SQL Server와 동일하지만 Azure 관련 주의사항이 두 가지 있습니다.

방언, 형식 및 스키마 레이아웃은 다른 SQL Server와 동일하며, 이것이 바로 이 버전을 사용하는 이유입니다. 두 가지 차이점이 있습니다.

• 기본 스키마는 dbo이며, 소스 간 참조는 바로 이 스키마를 따릅니다. — azure_sql.dbo.orders.
• Windows 및 Microsoft Entra 인증은 지원되지 않습니다. 에이전트는 SQL 로그인을 표시합니다.
• Azure SQL Database는 자체적인 데이터베이스 간 T-SQL 쿼리 기능을 제공하지 않으므로, 이러한 호스트의 경우 동일한 연결에서 두 번째 데이터베이스를 쿼리하는 옵션이 제공되지 않습니다. 이는 소스 간 쿼리에는 전혀 영향을 미치지 않습니다. — 이러한 데이터는 별도의 연결을 통해 쿼리 스트림으로 구성되므로 Azure SQL 데이터베이스를 다른 데이터베이스와 연결하는 작업은 정상적으로 작동합니다.
• 관리형 인스턴스는 동일한 호스트 이름 접미사를 공유하며 동일한 방식으로 연결됩니다. 별도의 네트워크 카드가 없으며 관리형 인스턴스 전용 동작도 없습니다.

-- 관리 서비스에 대한 일반 T-SQL, 읽기 전용 SELECT TOP (50) c.Name, COUNT(o.OrderId) AS Orders, SUM(o.Amount) AS Revenue FROM dbo.Customers AS c JOIN dbo.Orders AS o ON o.CustomerId = c.CustomerId WHERE o.PlacedAt >= DATEADD(day, -30, SYSUTCDATETIME()) GROUP BY c.Name ORDER BY Revenue DESC;