We are developing a database that consolidates few SQL Server DBs for a reporting requirement. Each DB has a number of views. No direct table or SP objects require to be accessible. All DBs and the new DB sitting in the same server. So we can develop cross-database queries quite easily with the Fully qualified object names.
i.e SELECT * FROM [SERVER].[DATABASE].[Schema].[View]
The problem is the depending database names differ between dev/ staging/ production environments of depending databases.
We have investigated the Synonym approach for the individual views and working fine. The advice we trying to seek from someone expert here is what is the best practice we should adhere to creating a single point to maintain this database alias instead of creating synonyms for each view so that we could do this once per environment and can maintain new queries same across different environments.
Related
I am working on migrating an application from one server to the other. According to the connection string of this application, it is touching different databases. Meaning a view query in DB1 will touch a table in DB2. So while migrating this application, I constant get to see chain of 'Database unavailable' errors and every time I see such error, I have to migrate that specific database.
I am wondering, since we have ER diagrams to know about relationships between tables in a database, is there any way in SQL server to know the relationships/linkages between different DATABASES in a server? Are there any tool that does this?
Depending on number of databases you have, here would be a somehow quick way you can find that out (number of required search = number of available databases in the server):
Use 'SQL Search' application of Red-get
(https://www.red-gate.com/dynamic/products/sql-development/sql-search/download)
and search for the other database names one after another by selecting
your database of interest. Select all objects.
If you have metadata oriented design (a Stored Procedure looping through the names of different other Stored Procedures / Functions from different databases which are stored in a table as metadata and executing them with a wrapper Stored Procesure), then you will have make use of SQL Locator software (http://www.sqllocator.com/Downloads.html) to search for database names in SQL Table values.
Both of the above software are free.
You need to have SSMS (SQL Server Management Studio) installed to be able to use this application. After installation, ‘SQL Search’ will be directly available in your SSMS as an add-on.
SQL Locator can be directly used by providing the SQL Server name and your SQL Server credential.
Note:- The above steps will help you find out the referenced databases from a certain database within the same SQL Server. If you need to find out databases from Linked Server (I do not believe your question is asking that anyways), then you will have to smartly utilize the same above tools to find the external server reference by searching the external server name.
SQL Server and Oracle terminology -
In SQL Server If I have two applications and want to keep the database completely separate, I could simply create 1 database for each application therefore I end up with 2 databases.
If I wanted to do the same thing in oracle, what do I need to create?
- create a new "Databases"? "Instance", "Schema", or "Tablespace" per application?
(Note, these two applications is the same application used by two different companies, that do not share data!)
Reference: http://www.codeproject.com/Tips/492342/Concept-mapping-between-SQL-Server-and-Oracle
Having worked with SQL Server a lot in the past, I have sympathy with trying to figure out how Oracle organizes things as I struggled with the same thing. My comments below are from SQL Server 2000 and 2003 so forgive me if things have changed since then.
Previous responders have been helpful. I think one problematic assumption here is that there is an exact "level" equivalency between SQL Server and Oracle. What I mean by "level" is something that occupies the same space in the hierarchies that you have diagrammed above (and which, btw, I think are a good place to start but might need a bit of editing in a couple of places, for example how you have diagrammed "user" and "schema" in the Oracle hierarchy, I might put them side-by-side.) I do not think these concept "levels" match exactly between the DB platforms.
A schema in Oracle is somewhat equivalent to a separate database in SQL Server but not entirely.
I would say that the "walls" -- not an exact technical term but oh well -- between databases in SQL server are a bit higher than the "walls" between schemas in Oracle. Others might disagree but here is my reasoning:
a. A schema in Oracle is a purely logical construct. It denotes who has ownership of objects. It has nothing to do with the physical location or layout of the objects. A tablespace (orthagonal concept, as noted by a previous poster) indicates the physical location of objects. A tablespace can hold objects that are in multiple schemas and vice versa. In SQL Server these two concepts are sort of merged into one -- a database is both tablespace and schema, more or less, although in some respects within a DB in SQL Server you then have multiple owners with various object ownership. This can get a bit confusing because as I remember (it's been a couple of years) if not using NT Authentication the users are defined at the server level and then have to "link" to the users in the individual DBs.
b. I remember finding it easier, or at least a bit simpler, to assure myself that users to two separate DBs in SQL Server had no access to the relative other user's DB than I have found it in Oracle.
c. Because a DB in SQL server represents both physical storage and logical ownership, you can detach the DB and move it to another SQL Server Instance and attach it. You can't do this with a schema in Oracle. I mean, you can datapump the data out or back it up or whatever to another server and another schema, but that all takes at least some scripting and such or at least a fair amount of clicking in Enterprise Manager. It doesn't give you the one-click "Detach DB" option that you have in SQL Server which makes it a lot easier to get the idea that SQL Server DBs are units that you can more-or-less move back and forth between databases.
To sum things up, I think either option would work. That is, 1) Create two separate instances of Oracle with one schema in each instance for each application, or 2) Create two separate schemas in one Oracle instance.
There are pros and cons for each option. Option 1 is probably going to be more work to set up and configure but will also give you more separation, independence, ability to have separate hardware, etc., for each DB. Option 2 will be quite a bit simpler but gives you less separation between the data and greater risk of configuration screw-ups or other things allowing users of one schema to access the other. It also means you have to be a bit more careful that someone writing a query accessing data in one schema doesn't use all the CPU and IO resources and starve a user on the other schema.
Also, yes, you could use pluggable databases in 12c. However, given the fact that you need to ask these questions (no shame, just pointing out where you're at) makes me hesitant about recommending what can easily be a more complex setup.
TL;DR -- SQL Server isn't Oracle and Oracle isn't SQL Server. Either option works and there are pros and cons to each.
If you're using 12.1 or later with the multitenant option, you could create separate pluggable databases in a single container database. The other option, which works in any version of Oracle, would be to create a separate schema. It would be possible, as well, to create a separate database, though that is generally not the preferred approach unless you have a particular need to do things like upgrade the database that one application is using without affecting the other.
Creating a Database
If you create a separate database, you'd end up with complete separate memory structures (i.e. the SGA and PGA for each database would be separate) as well as a completely separate set of background processes (each database would have its own log writer process(es) for example). That is a very heavyweight option-- you can't have too many databases on a single server before you start having a lot of contention for RAM, for scheduling all the background processes, etc. It does provide for the maximum separation between different applications-- each database can be running a different version of Oracle with a different set of initialization parameters-- but this also tends to increase the complexity of managing the environment. This generally only makes sense when you have third party applications that require a specific version of the database or a specific set of initialization parameters.
Creating a Schema
If you create a separate schema, you still have a single database so the two schemas are sharing the same memory structures (competing with each other for space in the SGA's buffer cache, for example), initialization parameters, etc. You have to exercise a modicum of planning to ensure that that the two don't interfere with each other-- you'd probably want to make sure that nether application creates public synonyms or at least that they won't wan to create the same public synonym as the other application-- but this is generally pretty trivial.
Creating a Pluggable Database
This only works in 12.1 and only if you have the multitenant option. This is the most similar to the SQL Server concept of creating a new database for each application.
You should create a new instance (schema) on the same database, where the schema in oracle is the same as the SQL server database
I am designing a multi-tenant database. Many actions that are needed on a per-tenant basis have been written as stored procedures. Almost all of them use dynamic SQL execution since I have not found a way to differentiate between the schemas other than with dynamic statements.
EXEC( 'SELECT * FROM ' + #SchemaName + '.Contacts' )
Is there any way to create a variable representing the schema so I can call the select statements without building them dynamically?
SELECT * FROM #TheSchema.Contacts
SQL Server 2008
FWIW I have found it much more useful to separate customers by database than by schema. Reasons?
All schemas can have identical procedures, thus derive them from model instead of having to create anything. Deployment to multiple databases is no more complex than deployment to multiple schemas, actually less so I'd argue, and the only difference is the application would have to know which database to reference instead of which schema.
Different customers can have different recovery models, be backed up on different schedules, etc. This can improve your backup/restore plan especially as the data set gets larger.
Having each customer in a separate database makes it very easy to move a tenant to a different server if they get too big for the current one. Extracting the data and objects for their schema only will be quite convoluted.
Some customers may legally and/or contractually require that you not store their data in the same database as other customers.
A simpler solution is to keep the stored procedure in each of the tenant databases and execute it inside them.
This question is a bit old, but I am looking into this option as a cost savings measure - since many cloud providers charge per database and the costs associated with storage are less - especially useful for multi-tenant small databases.
From what I understand, a default schema can be set for the login, thus, setting a schema per login would automatically use that schema for all queries and sprocs. Something to consider for those that comes across this question.
I've currently got a "Web" edition SQL Azure server with on database on it. I want to put another database on there but am unsure how the costing works. Will I need to pay the £9.99 per database or database server?
Does it make more sense just to set up a couple of different schemas in my existing database to try and reduce costs?
You pay per database. Creating schemas may make sense if cost is your concern. I have seen this done multiple times. However keep in mind that a few SQL Server/Azure features are schema independent. For example user-defined statistics and roles are schema independent. So as long as you don't use these features you should be good with a schema-based separation.
By default, objects (tables, stored procedures, etc) are set up with the dbo owner/schema (I think ms sql 2000 calls it owner, while ms sql 2005 calls it schema)
The owner/schema is really a role or user in the database. I've always left the default of dbo, but I've recently seen some examples in microsoft training books where some of their tables & stored procedures had different owners/schemas. When is it beneficial to do this and why?
The use of schemas is exceptionally beneficial when you have security concerns.
If you have multiple applications that access the database, you might not want to give the Logistics department access to Human Resources records. So you put all of your Human Resources tables into an hr schema and only allow access to it for users in the hr role.
Six months down the road, Logistics now needs to know internal expense accounts so they can send all of these palettes of blue pens to the correct location people. You can then create a stored procedure that executes as a user that has permission to view the hr schema as well as the logistics schema. The Logistics users never need to know what's going on in HR and yet they still get their data.
You can also use schemas the way cfeduke has suggested and just use them to group things in the object browser. If you are doing this, just be careful because you might end up creating Person.Address and Company.Address when you really just need a single dbo.Address (I'm not knocking your example, cfeduke, just using it to illustrate that both address tables might be the same or they might be different and that YMMV).
I've used schemas in the past sort of like namespaces so you could have multiple entities named Address ([Person].[Address], [Company].[Address]). The advantage to this is visual organization in SQL Management Studio, you can get the same thing by putting everything under one schema and naming tables with a single identifier (i.e. [dbo].[PersonAddress]).
I've also used them for developer vs. developer development prior to running SQL Server Developer Edition on all our dev machines (back when we had a centralized development database earlier in my career).
In SQL 2000 the Schemas where equivalent to database users, in SQL 2005 each schema is a distinct namespace that exists independently of the database user who created it.
I use schemas when I need to make features or modules that will be maybe used later in other projects, so I will be able to isolate the database objects that are used by the module.
Organization
In a dev environment, the production copy of the objects are dbo but developers can develop in their own schemas. Then code can reference the prod copy or their changes very simply. Using aliases can make this technique even more simple.
Also, a production database might support numerous systems or subsystems. You can use distinct schemas to keep those objects grouped.
This article explains it well, including the changes from SQL Server 2000 to 2005.