I have 2 servers. One used for backup as well as sharing with other external users and the other for live queries internally.
At the moment, on the backup database, the existing table is dropped and new table is added using the below code:-
DROP TABLE [dbo].[test]
SELECT * INTO test FROM [remote server].[remote database].[dbo].[remote table];
Is there another method instead of dropping and adding tables. Ideally, something that looks for any changes and syncs them using SQL Server Management Studio.
Edit:
My server is Express Edition and remote is SQL Standard
If you want to sync two tables in simplex communication way(One Directional) then you should go with transaction replication.
Sync will be performed on transaction commit for particular row.
Related
I have a database on Azure using the SQL Database (PaaS) offering.
I can't see or access the tempdb nor can I create it.
If I try to create the database I get the following error:
Msg 1801, Level 16, State 3, Line 10
Database 'tempdb' already exists. Choose a different database name.
Does anyone know what's going on here?
TempDB on Azure SQL Database is created and managed by Azure platform and the TempDB capacity has a limit in size based on the Azure SQL Database tier.
Hope this helps.
I am going to up tick Alberto since he is right about the service handling this system database.
I guess my main question is why are you using [tempdb]?
Before there was a push to the cloud, lazy SQL developers would create tables in [tempdb]. These tables should have been placed into a user defined staging database or schema.
Let's see if local/global temporary tables and user defined tables in [tempdb] are allowed.
-- local temp table
select 'Fee Fie Foo Fumb' as rhymes into #a
go
-- show the data
select * from #a
go
-- show my local tables
select * from tempdb.sys.tables
go
The expected results are shown below. Local and global temp tables are supported.
If we try the following create statement within Azure SQL database, the service is smart enough to know that you can not use [tempdb] directly.
Now, back to my first question.
Why are you trying to use and/or modify [tempdb]??
In rebuttal to Alberto, global temporary tables are now supported in Azure. The database being referenced by the session is a Basic tier (b0) level.
Can I alter my memory optimized table? Like adding column or changing data types etc. If yes, how to do it?
I am using SQL Server 2014
Thanks
According to Altering Memory-Optimized Tables (SQL Server 2014):
Performing ALTER operations on memory-optimized tables is not
supported. This includes such operations as changing the bucket_count,
adding or removing an index, and adding or removing a column. This
topic provides guidelines on how to update memory-optimized tables.
Updating the definition of a memory-optimized table requires you to create a new table with the updated table definition, copy the data to the new table, and start using the new table.
But it will be possible with SQL Server 2016:
In SQL Server 2016 Community Technology Preview 2 (CTP2) you can
perform ALTER operations on memory-optimized tables by using the ALTER
TABLE statement. The database application can continue to run, and any
operation that is accessing the table is blocked until the alteration
process is completed.
In the previous release of SQL Server, you had to manually complete
several steps to update memory-optimized tables.
I have a SQL Server 2012 Web Edition (11.0.5058.0) instance on a VPS which hosts two databases. I would like to mirror a couple of columns from 3 tables to the second database, but I don't have transactional replication installed.
So I have a Staff table on the source database - I just want the staff_code and unique_id - I have an Activity table - I just need the activity_code, description and unique_id.. etc.
What is the best way to go about this - would that be triggers? The data is not regularly updated, possibly once a week - but I would still like the synchronisation to be fast if possible?
The data in the source database may be deleted, updated or inserted, by another application, so I want to ensure the data in my database reflects that information correctly.
Thanks for any suggestions!
UPDATED: Table comparison example:
SELECT CASE WHEN NOT EXISTS
( SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [SOURCE-DATABASE].[dbo].[SOURCE-TABLE]
EXCEPT
SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [DESTINATION-DATABASE].[dbo].[DESTINATION-TABLE]
)
AND NOT EXISTS
( SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [DESTINATION-DATABASE].[dbo].[DESTINATION-TABLE]
EXCEPT
SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [SOURCE-DATABASE].[dbo].[SOURCE-TABLE]
)
THEN 'True'
ELSE 'False' //GRAB NEW OR UPDATED DATA
END AS result ;
As long as the two databases can be connected (e.g. can you do a SELECT * FROM SecondDB.dbo.Activity?), then I would just
set up a query (stand-alone, or in a stored procedure) that just checks whether or not the data on the source has changed
updates the second database using normal SELECT, INSERT, UPDATE and possibly DELETE statements
set up that query/stored procedure with a SQL Server Agent Job to run at regular intervals, e.g. once every night, once every week - whatever works for you
I don't think triggers would be a good choice here - triggers should be kept very small, lean, fast - and "replicating" to another database sounds like too much processing work for a nimble trigger.... (also if you triggers take a long time to complete, the calling application will have to wait for that whole time..... not good for your application performance!)
I have question regarding sql system database that what purpose of these database of msdb and msdb.
Thanks in advance.
Check MSdn : System Databases and Data : http://msdn.microsoft.com/en-us/library/aa174522%28v=sql.80%29.aspx
Microsoft® SQL Server™ 2000 systems have four system databases:
* master
The master database records all of the system level information for a SQL Server system. It records all login accounts and all system configuration settings. master is the database that records the existence of all other databases, including the location of the database files. master records the initialization information for SQL Server; always have a recent backup of master available.
* tempdb
tempdb holds all temporary tables and temporary stored procedures. It also fills any other temporary storage needs such as work tables generated by SQL Server. tempdb is a global resource; the temporary tables and stored procedures for all users connected to the system are stored there. tempdb is re-created every time SQL Server is started so the system starts with a clean copy of the database. Because temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down, there is never anything in tempdb to be saved from one session of SQL Server to another.
By default, tempdb autogrows as needed while SQL Server is running. Unlike other databases, however, it is reset to its initial size each time the database engine is started. If the size defined for tempdb is small, part of your system processing load may be taken up with autogrowing tempdb to the size needed to support your workload each time to restart SQL Server. You can avoid this overhead by using ALTER DATABASE to increase the size of tempdb.
* model
The model database is used as the template for all databases created on a system. When a CREATE DATABASE statement is issued, the first part of the database is created by copying in the contents of the model database, then the remainder of the new database is filled with empty pages. Because tempdb is created every time SQL Server is started, the model database must always exist on a SQL Server system.
* msdb
The msdb database is used by SQL Server Agent for scheduling alerts and jobs, and recording operators.
In Sqlsever Enterprise manager, there are some default databases are provided like tempdb and etc. What is significance of those databases?
TempDB is used for temporary work in SQL Server. Anytime you create a temp table that storage is done inside of TempDB. Here is a very good article from MSDN
Here are some points referenced from the MSDN:
The tempdb system database is a global resource that is available to all users connected to the instance of SQL Server and is used to hold the following:
•Temporary user objects that are explicitly created, such as: global or local temporary tables, temporary stored procedures, table variables, or cursors.
•Internal objects that are created by the SQL Server Database Engine, for example, work tables to store intermediate results for spools or sorting.
•Row versions that are generated by data modification transactions in a database that uses read-committed using row versioning isolation or snapshot isolation transactions.
•Row versions that are generated by data modification transactions for features, such as: online index operations, Multiple Active Result Sets (MARS), and AFTER triggers.
Operations within tempdb are minimally logged. This enables transactions to be rolled back. tempdb is re-created every time SQL Server is started so that the system always starts with a clean copy of the database. Temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down. Therefore, there is never anything in tempdb to be saved from one session of SQL Server to another. Backup and restore operations are not allowed on tempdb.
There is also the master database (holds information about all databases), Model database, MSDB (stores information on the sql agent, dts, jobs, etc).
More info here as well
MASTER - This keeps all server-level information, and meta-data about all databases on the server. Don't lose this :)
MSDB - Holds information about SQL Agent jobs and job run history
TEMPDB - Used as a temporary "work space" for temporary tables and lots of other stuff (like sorting and grouping)
MODEL - When you create a new, blank database, it makes a copy of MODEL as a template
DISTRIBUTION - (You will only see this on servers where you have set up replication) Holds records pending for replication.
SQL Server uses tempdb to store internal objects such as the intermediate results of a query. You can get more details here.