SQL 2008 R2 中的 Unicode 压缩是否会导致 GUID 损坏？
最近，我们的生产 SQL 2008 R2 数据库遇到了一些问题，必须将大多数数据库故障转移到日志传送的热备件。今天早上，我发现一些非常奇怪的 GUID 值分散在我们的数据库集中。作为背景，我们有一个主客户端数据库，它保存有关已安装客户端的各种信息，包括在其他表和其他数据库中引用的主 client_guid。我发现某些支持数据库中的 GUID 已被汉字和西里尔字符损坏。例如：在我们的主客户端数据表中，特定记录的 GUID 为“4d86854e-d699-4bce-a98b-c34fcc909453”，但在 Analytics 数据库中，相同的 GUID 显示为“4d86854e-d699-4bce瞧ＲĹ” Ɏ-c34fcc909453'。
今天我绞尽脑汁想弄清楚这是怎么发生的。我偶然发现了一些有关 Unicode 压缩的信息，并且想知道 SQL Server 是否有可能在数据库恢复期间破坏这些 GUID。
我们的数据库系统中的排序规则设置为 SQL_Latin1_General_CP1_CI_AS。
我想知道是否有人对这个问题有任何见解。
We recently had some trouble with our production SQL 2008 R2 databases and had to failover to log-shipped warm spares for most of our databases. This morning I found some very odd GUID values scattered throughout our set of databases. For background, we have a main clients database, that holds various information about installed clients, including the master client_guid that is referenced in other tables and other databases. I am seeing that the GUIDs in some of the support dbs have become corrupted with Kanji and Cyrillic characters. For example: In our main client data table, a particular record had a GUID of '4d86854e-d699-4bce-a98b-c34fcc909453', but in the Analytics database that same GUID is showing up as '4d86854e-d699-4bce瞧ＲĹ（Ɏ-c34fcc909453'.
I have been wracking my brain today trying to figure out how this might have happened. I stumbled upon some information about Unicode compression, and I was wondering if it might be possible for SQL Server to mangle these GUIDs during a database restore.
Collation throughout our db system is set to SQL_Latin1_General_CP1_CI_AS.
I'm wondering if anyone has any insight into this problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论