Skip to content

Commit 6d8fa99

Browse files
Clare Zheng (Shanghai Wicresoft Co Ltd)Clare Zheng (Shanghai Wicresoft Co Ltd)
Clare Zheng (Shanghai Wicresoft Co Ltd)
authored and
Clare Zheng (Shanghai Wicresoft Co Ltd)
committed
Update according to comment
1 parent 31e5c89 commit 6d8fa99

File tree

2 files changed

+52
-54
lines changed

2 files changed

+52
-54
lines changed

‎articles/data-factory/connector-oracle.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -507,8 +507,8 @@ When you copy data from and to Oracle, the following interim data type mappings
507507
| LONG RAW |Byte[] |Byte[] |
508508
| NCHAR |String |String |
509509
| NCLOB |String |String |
510-
| NUMBER (p,s) |Int16, Int32, Int64, Single, Double, Decimal (p <= 256,s <= 130) |Decimal, String (if p > 28) |
511-
| NUMBER without precision and scale | Decimal |Double |
510+
| NUMBER (p,s) |Int16, Int32, Int64, Single, Double, Decimal |Decimal, String (if p > 28) |
511+
| NUMBER without precision and scale | Decimal (256,130) |Double |
512512
| NVARCHAR2 |String |String |
513513
| RAW |Byte[] |Byte[] |
514514
| TIMESTAMP |DateTime |DateTime |

‎articles/data-factory/connector-troubleshoot-oracle.md

Lines changed: 50 additions & 52 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,56 @@ ms.custom: has-adal-ref, synapse
1616

1717
This article provides suggestions to troubleshoot common problems with the Oracle connector in Azure Data Factory and Azure Synapse.
1818

19+
## Version 2.0
20+
21+
### Error message: ORA-12650: No common encryption or data integrity algorithm
22+
23+
- **Symptoms**: You meet the following error message: `ORA-12650: No common encryption or data integrity algorithm`
24+
25+
- **Cause**: The client and server failed to agree on a common encryption/data integrity behavior or algorithm during negotiation. The default client-side configurations are as follows:
26+
27+
- `encryptionClient`: `required`
28+
- `encryptionTypesClient`: `(AES256)`
29+
- `cryptoChecksumClient`: `required`
30+
- `cryptoChecksumTypesClient`: `(SHA512)`
31+
32+
- **Recommendation**:
33+
34+
1. Check the server-side configurations, including SQLNET.ENCRYPTION_SERVER and SQLNET.CRYPTO_CHECKSUM_SERVER. Update the linked service additional properties `encryptionClient` and `cryptoChecksumClient` on the client side if needed. Note that the actual behavior is determined by the negotiation outcome between the client and server configuration, as shown below.
35+
36+
| Client\Server | rejected | accepted | requested | required |
37+
|---------------|----------|----------|-----------|----------|
38+
| rejected | OFF | OFF | OFF | Connection fails |
39+
| accepted | OFF | OFF | ON | ON |
40+
| requested | OFF | ON | ON | ON |
41+
| required | Connection fails | ON | ON | ON |
42+
43+
1. Check the server-side configurations, including SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER. Update the linked service additional properties `encryptionTypesClient` and `cryptoChecksumTypesClient` on the client side to ensure that a common algorithm can be found between them. You can set `encryptionTypesClient` to `(AES128, AES192, AES256, 3DES112, 3DES168)` and `cryptoChecksumTypesClient` to `(SHA1, SHA256, SHA384, SHA512)` to include all supported client-side algorithms.
44+
45+
46+
### Decimal precision too large error
47+
48+
- **Symptoms**: When copying NUMBER type columns from Oracle, the copy may fail or the data written to the sink cannot be further consumed by other tools because the decimal precision is too large.
49+
50+
- **Cause**: To avoid data loss, the decimal precision used to represent the Oracle NUMBER type is 256, which exceeds the max precision supported by the sink connector or downstream consumer.
51+
52+
- **Recommendation**:
53+
54+
Resolve this issue by using one of the two methods provided below:
55+
56+
- Use a query to explicitly cast the column to BINARY_DOUBLE. For example:
57+
`SELECT CAST(ColA AS BINARY_DOUBLE) AS ColB FROM TableA.`
58+
59+
- Set the linked service additional property `supportV1DataTypes` to `true`, which ensures that version 2.0 uses the same data type mappings as version 1.0.
60+
61+
### Error message: ORA-00933: SQL command not properly ended
62+
63+
- **Symptoms**: You meet the following error message: `ORA-00933: SQL command not properly ended`
64+
65+
- **Cause**: Currently Oracle version 2.0 doesn’t support the query ended with a semicolon.
66+
67+
- **Recommendation**: Remove the semicolon at the end of the query.
68+
1969
## Version 1.0
2070

2171
### Error code: ArgumentOutOfRangeException
@@ -83,58 +133,6 @@ There are three error messages associated with this error code. Check the cause
83133

84134
- **Recommendation**: Specify the connection string property `CryptoProtocolVersion=TLSv1.2`.
85135

86-
87-
## Version 2.0
88-
89-
### Error message: ORA-12650: No common encryption or data integrity algorithm
90-
91-
- **Symptoms**: You meet the following error message: `ORA-12650: No common encryption or data integrity algorithm`
92-
93-
- **Cause**: The client and server failed to agree on a common encryption/data integrity behavior or algorithm during negotiation. The default client-side configurations are as follows:
94-
95-
- `encryptionClient`: `required`
96-
- `encryptionTypesClient`: `(AES256)`
97-
- `cryptoChecksumClient`: `required`
98-
- `cryptoChecksumTypesClient`: `(SHA512)`
99-
100-
- **Recommendation**:
101-
102-
1. Check the server-side configurations, including SQLNET.ENCRYPTION_SERVER and SQLNET.CRYPTO_CHECKSUM_SERVER. Update the linked service additional properties `encryptionClient` and `cryptoChecksumClient` on the client side if needed. Note that the actual behavior is determined by the negotiation outcome between the client and server configuration, as shown below.
103-
104-
| Client\Server | rejected | accepted | requested | required |
105-
|---------------|----------|----------|-----------|----------|
106-
| rejected | OFF | OFF | OFF | Connection fails |
107-
| accepted | OFF | OFF | ON | ON |
108-
| requested | OFF | ON | ON | ON |
109-
| required | Connection fails | ON | ON | ON |
110-
111-
1. Check the server-side configurations, including SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER. Update the linked service additional properties `encryptionTypesClient` and `cryptoChecksumTypesClient` on the client side to ensure that a common algorithm can be found between them. You can set `encryptionTypesClient` to `(AES128, AES192, AES256, 3DES112, 3DES168)` and `cryptoChecksumTypesClient` to `(SHA1, SHA256, SHA384, SHA512)` to include all supported client-side algorithms.
112-
113-
114-
### Decimal precision too large error
115-
116-
- **Symptoms**: When copying NUMBER type columns from Oracle, the copy may fail or the data written to the sink cannot be further consumed by other tools because the decimal precision is too large.
117-
118-
- **Cause**: To avoid data loss, the decimal precision used to represent the Oracle NUMBER type is 256, which exceeds the max precision supported by the sink connector or downstream consumer.
119-
120-
- **Recommendation**:
121-
122-
Resolve this issue by using one of the two methods provided below:
123-
124-
- Use a query to explicitly cast the column to BINARY_DOUBLE. For example:
125-
`SELECT CAST(ColA AS BINARY_DOUBLE) AS ColB FROM TableA.`
126-
127-
- Set the linked service additional property `supportV1DataTypes` to `true`, which ensures that version 2.0 uses the same data type mappings as version 1.0.
128-
129-
### Error message: ORA-00933: SQL command not properly ended
130-
131-
- **Symptoms**: You meet the following error message: `ORA-00933: SQL command not properly ended`
132-
133-
- **Cause**: Currently Oracle version 2.0 doesn’t support the query ended with a semicolon.
134-
135-
- **Recommendation**: Remove the semicolon at the end of the query.
136-
137-
138136
## Related content
139137

140138
For more troubleshooting help, try these resources:

0 commit comments

Comments
 (0)