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.
Related
Is there a proper way to move a SQL Server 2016 sharded database from self-hosted to Azure Database?
I have a SQL Server 2016 sharded database that is part of the platform (Sitecore 10) I'm working with. It has a Shard Map Manager database and two Shard databases. I want to migrate the databases from self-hosted to Azure Database.
When the database is in a SQL Server Instance, it has one login mapped to the Shard Map Manger user and both Shard users. Everything works great. Since Azure Database does not use logins the same way and the databases are partially contained, I created separate users in each database in Azure with the same name and password.
Next, I migrated the schema with Azure Data Migration Services and then the data. There are some stored procedures that Sitecore provides to setup permissions and I ran those.
Finally, I updated the ServerName and DatabaseName fields in the [__ShardManagement].[ShardsGlobal] table for the ShardMapManager DB and the [__ShardManagement].[ShardsLocal] table in both Shard databases to match the new server and database names.
When I updated the app to use the new database, it spewed errors into the log, ultimately tracking to a failed login for the user. There are 13 other databases for the app which were also migrated and work fine, only the sharded database does not work in the app. I ran a PowerShell script that tests the connection string for all of the databases. All of the connection strings were successful. Backing out only the connection strings for the sharded database fixes the errors proving that the connection to the sharded databases is the problem.
What did I do wrong and what should I do to fix it?
If the requirement is only to migrate the databases from local to Azure, the best possible way is to use SQL Server Management Studio (SSMS).
The advantage is that you can mention the new database name on Azure while migrating itself and hence no need to change later. But just make sure same named database shouldn't available already in Azure SQL Server.
You can follow the migration steps from my this answer.
Also, my suggestion is to go through the official documents Assessment rules for SQL Server to Azure SQL Database migration, Troubleshoot connecting to the SQL Server Database Engine. I'm sure you will find the useful insights there which could help to make migrated database work properly with the apps.
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.
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.
in my development environment we support the application both on MSSQL Server as well as Oracle. The database schema of both of these RDBMS are same.
while development we found that the developer made a mistake and forgot to change the oracle database for the last 1 yr. therfore the oracle script is quite behind in term of schema from SQL Server schema script.
now the question is how i can compare the two RDBMS systems to find the difference and make the oracle script updated
If there are no track log from which it's possible to find and reproduce all changes applied to SQL Server since first detected inconsistency with Oracle version, or that changes was applied, but only partially, you really need to compare objects presented in both databases.
In this case setup a link between databases on any side and use system dictionary views to compare table structures and other objects to find differences and, possible, to generate script for Oracle scheme rollup.
If you want to act from MS SQL Server side:
Install and configure Oracle Instant Client
Install Oracle ODAC
Follow Microsoft recomendations (64-bit version)
Connect as any user with dba role (or use same Oracle schema where object resides) to Oracle from MS SQL database
If you want to act from Oracle Server side:
Install and configure Oracle Database Gateway for SQL Server.
Create database link to MS SQL Server.
After successful configuration you may join Information schema views on SQL Server side with Data dictionary views on Oracle side to find differences.
Of course there are many troubles at this way like different data types, but it gives a chance to automate at least part of work.
I read somewhere that "table access level security" does not exist for sql server azure. Unfortunately, I cannot find the blog/page anymore. Can experts please clarify this, ideally with some evidence? Thanks.
You have heard it wrong probably; It's allowed. Per MSDN Documentation On: SQL Server Feature Limitations (Azure SQL Database)
The limitation list doesn't include table level permission security.
Again, per MSDN Documentation On: GRANT Object Permissions it says
Applies to: SQL Server (SQL Server 2008 through current version),
Azure SQL Database.
Which apparently implies that, you can grant table level access permission in SQL Azure as well.