Categories
Architecture

Database Spotlight: Application Registry Service DB

Unlike other databases that SharePoint 2010 creates, the Application Registry Service Database is actually included in the mix for backward compatibility of SharePoint Server 2007 Business Data Catalog connection information and other information pertinent to the BDC API.

By default, the database name is “Application_Registry_Service_DB_<GUID>”.  I’m not quite certain why, but I’m not so much a fan of the out of the box naming of databases with a GUID appended to the end – though I guess it does ensure that you’re never going to inadvertently create one on the fly that has the same name as others.

Similar to the BDC, the Application Registry Service database is read-heavy since there isn’t any writing done with the BDC Smile. And though the services architecture is a bit more broken out, you can only have a single Application Registry Service per farm, which means that you can only have a single database associated with your farm, which in turn means get ready to watch it grow should you be migrating several BDCs into your farm while you prep them for conversion to Business Connectivity Services candidates.

Fortunately for scalability purposes, it is possible to mirror this database within a farm to ensure availability of data for the BDCs to operate, however it’s not possible to mirror the database or use log shipping to mirror the database onto another SQL instance. Perhaps keeping a backup handy would be helpful should the data become corrupted or your server’s SAN melt.

A visualization of the tables and associated columns is depicted here:

Application_Registry_Service_DB_GUID

If you’re wondering what the tables and their associated columns look like for the Application Registry, then look no further as they are as follows:

Application_Registry_Service_DB_GUID
  AR_Action
    EntityId
    Icon
    Id
    IsDisplayed
    IsOpenedInNewWindow
    Position
    Url
 
AR_ActionParameter
    ActionId
    Id
    Index
 
AR_AdminLocks
    Id
    LockId
  AR_ApplicationRegistry
    Id
  AR_Association
    Id
  AR_AssociationMember
    AssociationId
    EntityId
    EntityRole
    Id
  AR_CacheCounters
    MetadataObjectType
    ObjectCacheCounter
    RelationshipCacheCounter
  AR_Class
    Id
    SystemId
  AR_DefaultValue
    Id
    MethodInstanceId
    TypeDescriptorId
    Value
  AR_Entity
    EstimatedInstanceCount
    Id
  AR_ExternalAssociation
    Id
    MappingTableName
    SourceEntityId
    TargetEntityId
  AR_FilterDescriptor
    Id
    MethodId
    TypeName
  AR_Identifier
    EntityId
    Id
    OrdinalNumber
    TypeName
  AR_LocalizedName
    Id
    LCID
    LocalizedName
    MetadataObjectId
  AR_MetadataObject
    Id
    IsCached
    Name
    Version
  AR_MetadataObjectSecurity
    DisplayName
    Id
    IdentityName
    MetadataObjectId
    RawSid
    Rights
  AR_Method
    ClassId
    Id
    IsStatic
  AR_MethodInstance
    Id
    MethodId
    ReturnTypeDescriptorId
    Type
  AR_Parameter
    Direction
    Id
    MethodId
    OrdinalNumber
    TypeReflectorTypeName
 
AR_Property
    Id
    MetadataObjectId
    Name
    Value
 
AR_System
    ConnectionFactoryTypeName
    Id
    SystemEntityTypeName
    SystemUtilityTypeName
 
AR_SystemData
    Data
    Id
    Length
    Name
    SystemId
 
AR_SystemInstance
    Id
    SystemId
 
AR_TypeDescriptor
    ContainsFilterDescriptor
    ContainsIdentifier
    FilterDescriptorId
    Id
    IdentifierId
    InterpretedTypeName
    IsCollection
&#160
;   ParameterId
    ParentTypeDescriptorId
    TypeName

A downloadable copy of the Map in PDF format is available here.

Categories
Architecture

SharePoint 2010 Database Names

While SharePoint Server 2010 has several enhancements for Administrators including such capabilities of an offline database restoring a list item or document, there are still some curiosities that I’ve got as to the planning of the underlying system.

For instance, it would seem that for such a refined product with so many enhancements that items such as the underlying databases might follow a naming convention of some sort. For a standard SharePoint Server 2010 Enterprise edition installation, out of the box you’ll have the following databases:

Application_Registry_Service_DB_GUID
Bdc_Service_DB_GUID
Managed Metadata Service_GUID
PerformancePoint Service Application_GUID
Search_Service_Application_CrawlStoreDB_GUID
Search_Service_Application_DB
Search_Service_Application_PropertyStoreDB_GUID
Secure_Store_Service_DB_GUID
SharePoint_AdminContent_GUID
SharePoint_Config
StateService_GUID
User Profile Service Application_ProfileDB_GUID
User Profile Service Application_SocialDB_GUID
User Profile Service Application_SyncDB_GUID
WebAnalyticsServiceApplication_ReportingDB_GUID
WebAnalyticsServiceApplication_StagingDB_GUID
WordAutomationServices_GUID
WSS_Content
WSS_Logging

As you can see, the naming convention seems to vary dependent on the team within the product group that was developing the capability, feature set or workload.  For instance, some of the databases include an “_DB"_” and other times the database name has a concatenation of the “DB”.  Further, it’s interesting in seeing how they delineate words, in some instances using spaces, others underscores and others just capitalization of letters to delineate the database.

Interesting that it wasn’t polished to be uniform eh?