0

Could anyone explain why the NEWSEQUENTIALID() generates a partly utilized GUID.

Software I am writing uses Entity Framework, and whenever creating an entry into a table that uses GUID's as primary keys, for some reason the GUID's "node" component is never used.

This is how the entity id is marked up in code first and its nothing special:

[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public Guid Id { get; set; }

Here are some of the entries when created:

30F74F3E-F36B-1410-B730-800000000000
31F74F3E-F36B-1410-B731-800000000000
32F74F3E-F36B-1410-B732-800000000000
33F74F3E-F36B-1410-B733-800000000000
34F74F3E-F36B-1410-B734-800000000000

As you can see the "node" component is always: 80 00 00 00 00 00

Is there a method of configuration (either as code first or directly running sql on the database) to let mssql know that it should use the "node" component if possible? I dont want to random GUID's as this is a massive performance hit when searching.

If NEWSEQUENTIALID() is not configurable then what is the design reason behind not using the "node" component of the GUID?

Gelion
  • 531
  • 7
  • 18
  • 2
    The last bytes should be the MAC address of the machine's primary network interface, so the fact that it doesn't change is to be expected, even if the value is not. Are you testing this on a virtual machine, or something else with an unusual network configuration? – Jeroen Mostert May 23 '18 at 10:22
  • The server software is running on a VM. These last bytes dont change ragardless if the VM is Linux or Windows and Mono / .NET respectively – Gelion May 23 '18 at 10:25
  • Are you saying you're running SQL Server on a Linux VM and still getting the same results? Because on Linux it explicitly uses an algorithm where it [generates the "MAC address" and stores it](https://blogs.msdn.microsoft.com/bobsql/2018/02/22/sql-server-on-linux-cu4-newsequentialid-uuid/)... so that would be unusual. – Jeroen Mostert May 23 '18 at 10:29
  • Sorry I'll clarify, my software is running on a linux VM, the mssql database is running on a dedicated non-VM Linux server. – Gelion May 23 '18 at 10:31
  • 1
    To be clear, the location of your software will never influence the results of `NEWSEQUENTIALID()` -- the "node" part is the MAC address (or equivalent) of the *server*, never that of the client, so varying that will have no effect anyway. If you need partitioning by client nodes, you'll need a second column or you'll need to produce sequential GUIDs on the client side. (To troubleshoot the weird node id of the server, check the `instance_id` file that it should have and/or any reports in the error log.) – Jeroen Mostert May 23 '18 at 10:34
  • 1
    This looks to be a bug with SQL Server on Linux.. (https://stackoverflow.com/questions/44649830/newsequentialid-is-broken-in-sql-server-for-linux) Nothing relating to EF or the Linux client. – Steve Py May 23 '18 at 10:42
  • ah thats good to know. I'll check my mssql version, may not have auto-updated. – Gelion May 23 '18 at 10:49
  • This was fixed from the looks of it in one of the updates, did an update to mssql on linux and has fixed GUID generation. – Gelion May 23 '18 at 11:03

0 Answers0