Questions Regarding SQL Server Licensing
Comments
-
We are currently architecting an on-prem Decisions implementation. Attached is the architecture diagram.
[ul][li]PROD – Two Windows Server instances, One SQL Server Application Database[/li][li]QA – Two Windows Server instances, One SQL Server Application Database[/li][li]DEV – One Windows Server instance, One SQL Server Application Database[/li][li]Repository - One SQL Server Repository Database[/li][/ul]
Questions:
Is project data that is uploaded to/downloaded from the repository also stored in each environment’s application database?
Do all our instances of SQL Server need PROD licenses due to the transitory nature of the data in the repository database? -
[font=Roboto, Arial, Helvetica, sans-serif]A Repository server should have its own separate database from any other Decisions servers in your network. The database for a given Decisions server can exist within the same SQL Server instance as other Decisions servers, provided each database in that SQL Server instance is given a unique name. That is one uniquely named database per server or cluster - in this case, four separate databases. It is not necessary to have unique database names for Decisions servers if they are installed on separate instances of SQL Server. By default, projects are not automatically updated or pushed from Repositories to Dev servers. The version of a project stored in a given Dev server will not change unless it is checked out from a Repo server. For example, the Dev01 server pushes an update to a Repository server as a new branch, but Dev02s local version of the project will remain unchanged. The Dev02 server will have to pull the most recent version of the project from the Repo server for the changes made by the Dev01 server to appear in Dev02s local version of the project. Your SQL Server instances will only need a full license if youre expecting to have to restore databases from backups on other SQL Server instances over 10GB in size, to be utilizing a niche feature like always on replication for a disaster recovery server, or to have millions of records in tables or many thousands of concurrent users.[/font]
[font=Roboto, Arial, Helvetica, sans-serif]
[/font]
[font=Roboto, Arial, Helvetica, sans-serif]You shouldnt need PROD SQL licenses for Non-Prod Decisions servers in my opinion. The dev server and repo servers do not have/send actual data around. They just have the configuration data of the workflow objects. We dont export data between environments. [/font]Configuration data here would mean the data of a flow or a form itself. These are created in dev and saved to the database. They are then exported to production at which point they are saved into the database. When these flows run they generated data that is saved into the appropriate database(dev/prod). The configuration data item has to be built in decisions on a dev server so it should be considered dev data, but we have never had this question put to us before. This question sounds like it is mostly about how the data is used. From my perspective, there is a clear distinction between prod and dev in its use here. At the end of the day, we are just saving both configuration and transaction data as data in normal database tables. Hope this helps, happy to join a call and discuss in more detail
Howdy, Stranger!
Categories
- 4.2K All Categories
- 67 General
- 11 Training
- 202 Installation / Setup
- 1.1K Flows
- 106 Rules
- 262 Administration
- 212 Portal
- 490 General Q & A
- 695 Forms
- 333 Reports
- 3 Designer Extensions
- 47 Example Flows
- 52 CSS Examples
- 1 Diagram Tile
- 7 Javascript Controls
- 179 Pages
- 5 Process Mining
- New Features
- 179 Datastructures
- 69 Repository
- 221 Integrations
- 28 Multi-Tenant
- 27 SDK
- 78 Modules
- 56 Settings
- 25 Active Directory
- 12 Version 7
- 35 Version 8
- 83 Lunch And Learn Questions