Your external object store must be configured to allow SQL Engine access.
To configure the external storage, set the SQL statements credentials for USER and PASSWORD as shown in the following table.
| System/Scheme | USER | PASSWORD |
|---|---|---|
| AWS | Access Key ID | Access Key Secret |
| Azure / Shared Key | Storage Account Name | Storage Account Key |
| Azure Shared Access Signature (SAS) | Storage Account Name | Account SAS Token |
| Google Cloud (S3 interop mode) | Access Key ID | Access Key Secret |
| Google Cloud (native) | Client Email | Private Key |
| On-premises object stores | Access Key ID | Access Key Secret |
| Public access object stores | <empty string> Enclose the empty string in single straight quotes: USER '' |
<empty string> Enclose the empty string in single straight quotes: PASSWORD '' |
Define access to Azure containers using Access Keys or Account Shared Access Signatures (SAS). Access key information provides you full control over the entire account. You can also define SAS on Containers or on objects within containers for a more fine-grained authentication approach. NOS uses both types of authentication and does not require the type of secret supplied for authentication. After you configure the authentication on Azure, you can use the storage account name and key or SAS token in CREATE AUTHORIZATION and READ_NOS statements.
See Teradata Vantage™ - Native Object Store Getting Started Guide for information on creating an authorization object, function mapping, or the USING clause with ACCESS_ID and ACCESS_KEY.
- Query a modest dataset size when connected to Cloud storage for best performance.
- See Risks.