docs: added missing ids

docs/reference/index-modules/fielddata.asciidoc

@@ -149,6 +149,7 @@ field data format.
     Computes and stores field data data-structures on disk at indexing time.
 
 [float]
+[[global-ordinals]]
 ==== Global ordinals
 
 Global ordinals is a data-structure on top of field data, that maintains an
@@ -182,6 +183,7 @@ ordinals is a small because it is very efficiently compressed. Eager loading of
 can move the loading time from the first search request, to the refresh itself.
 
 [float]
+[[fielddata-loading]]
 === Fielddata loading
 
 By default, field data is loaded lazily, ie. the first time that a query that

docs/reference/mapping/fields/parent-field.asciidoc

@@ -35,11 +35,11 @@ Parent/child queries (`has_child` & `has_parent`) can't be used in index aliases
 
 ==== Global ordinals
 
-Parent-child uses <<index-modules-fielddata-global-ordinals,global ordinals>> to speed up joins and global ordinals need to be rebuilt after any change to a shard.
+Parent-child uses <<global-ordinals,global ordinals>> to speed up joins and global ordinals need to be rebuilt after any change to a shard.
 The more parent id values are stored in a shard, the longer it takes to rebuild global ordinals for the `_parent` field.
 
 Global ordinals, by default, are built lazily: the first parent-child query or aggregation after a refresh will trigger building of global ordinals.
-This can introduce a significant latency spike for your users. You can use <<index-modules-fielddata-fielddata-loading,eager_global_ordinals>> to shift the cost of building global ordinals
+This can introduce a significant latency spike for your users. You can use <<fielddata-loading,eager_global_ordinals>> to shift the cost of building global ordinals
 from query time to refresh time, by mapping the _parent field as follows:
 
 ==== Memory usage