plz give me detail of Contained Database = true in Sql Server 2012
how to use and why ?
How to Migrate to a Partially Contained Database:
USE [master]
GO
ALTER DATABASE [Accounting] SET CONTAINMENT = PARTIAL
GO
What are Contained Databases in SQL Server 2012:
A contained database is a database that is isolated from other
databases and from the instance of SQL Server that hosts the database.
SQL Server 2012 helps user to isolate their database from the instance
in 4 ways.
Much of the metadata that describes a database is maintained in the database. (In addition to, or instead of, maintaining metadata in
the master database.)
All metadata are defined using the same collation.
User authentication can be performed by the database, reducing the databases dependency on the logins of the instance of SQL Server.
The SQL Server environment (DMV's, XEvents, etc.) reports and can act upon containment information.
Related
When a database is fully contained, it is having all the objects within the database boundary. It manages connection also at database level. Contained Database
I have few questions:
If I host a contained database in Azure SQL Single DB then what is
the difference between a Azure SQL single db and a contained database
as Azure SQL single db ?
Why do we have a separate offering as Azure SQL Single Db, when
contained database also is something similar to it ?
Does making a database as contained database will help in easier
migration to Azure SQL single DB ?
In Azure speak, "single" is a deployment option that differentiates Azure SQL Database from Managed and Elastic Pools. There's really no difference from a containment perspective because Single and Azure SQL Database are one and the same.
Azure SQL Database inherently provides containment features like database-level user authentication. With on-prem SQL Server databases, one must opt-in for with CONTAINMENT=PARTIAL
to permit database-level authentication.
Does making a database as contained database will help in easier migration to Azure SQL single DB ?
CONTAINMENT=PARTIAL permits database-level authentication in on-prem versions, facilitating migration of database security principals. As long as user database entities stay within the database boundary and one doesn't need features unavailable in contained databases (e.g. CDC), migration is typically easy.
A consideration, though, is that partially contained databases implicitly use catalog collation Latin1_General_100_CI_AS_KS_WS_SC whereas Azure SQL Database catalog collation must be either the chosen DATABASE_DEFAULT collation or SQL_Latin1_General_CP1_CI_AS. This is generally an issue only when case-sensitivity of object/variables names is desired.
Existing uncontained references can be identified by querying sys.dm_db_uncontained_entities:
SELECT * FROM sys.dm_db_uncontained_entities;
The above query will also identify dynamic SQL references that will need to be examined manually.
I want to replicate my SQL Server 2016 SP1 production database to an AlwaysOn replication in another database of the same type.
I understand the replication will be read-only, but what happens when users make changes to the source DB?
For example, if I add a view to the source DB, does that view immediately get created in the replication?
What about User permissions, Logins, Stored Procedures, Indexes, even entire tables? If those are created on my source DB, do they instantly replicate over to an AlwaysOn replication?
If these all do replicate, is there anything which doesn't replicate over using an AlwaysOn?
If these all do replicate, is there anything which doesn't replicate over using an AlwaysOn?
Everything stored in the database is replicated. Tables, Indexes, Views, Proc, Users, Roles, etc. Everything that would be included in a Database Backup is replicated.
Everything stored outside the database is not replicated. Logins, SQL Agent Jobs, SSIS Packages, Instance Configuration settings, etc.
In my SQL Server database I need to mantain the tables linked and in sync with the tables of an MS Access .mdb file.
Lets say I update something or add something in the MS Access database via my own application.
I want those changes reflected in the SQL Server database.
I need a way to push the updates to the SQL Server database, or a way to update the SQL Server database with the new data when I connecto to it.
Trying to be clear: source must be the .mdb file database and destination must be the SQL server database. I need to keep them in sync.
Both databases have the same tables.
I have read a lot of posts, even this one: From SQL Server how do I read from an MS Access database to UPDATE data in one or more table columns? that seems to be the solution, but I can figure out the steps.
The official tool for this is:
SQL Server Migration Assistant for Access (AccessToSQL)
It has a migration feature that, when run, will replicate (adjust) the table schema in the database in SQL Server to match that of the Access database.
I have DB in my SQL Server. I want to replicate the same DB with all the Views inside it into Azure and sync the same SQL Server DB with replicated DB on Azure on daily basis.
I have no idea about Azure.
You can migrate a SQL Server 2005 or later database to a single or pooled database in Azure SQL Database. For best performance during the import process, it’s better to drop indexed views and recreate them once finished. For more details, you may refer to this article: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-cloud-migrate.
You can set up Azure SQL Data Sync by creating a hybrid sync group that contains both Azure SQL Database and SQL Server instances. For more details on how to achieve this, you may refer to this document: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-get-started-sql-data-sync.
Note: Does SQL Data Sync fully create and provision tables?
Views and Stored Procedures are not created on the destination database.
You can use SQL Data Sync to sync the base tables of your views but SQL Data Sync cannot sync views. Sync data from views is quite complex and not always achievable and for that reason SQL Data Sync does not do it.
Use the step-by-step procedure described here to configure the synchronization. You need to make your SQL Server instance a "hub", your SQL Azure Database a "member" on the sync configuration. Configure the "Sync frequency" parameter/field to occur every X days or X hours.
in SQL Server users are first registered on the server level as Logins, and after that they are added to all necessary databases on that server as Users.
Is there something comparable in Oracle? I understand that the Oracle object Tablespace kind of represents the database object in SQL Server, but nevertheless it appears to me as if in Oracle solely database users are registered which gain access to database objects via fine-granular GRANT/DENY operations and role memberships.
Thanks in advance,
Jan
Check this post:
Difference between a user and a schema in Oracle?
I (too) started with Sql Server and had to learn the different phrasing for Oracle.