New answers tagged migration
0
In Working with tempdb in SQL Server 2005 Microsoft writes:
Following are some additional configuration and performance recommendations for tempdb:
Create the tempdb database on a fast I/O subsystem. Use disk striping to numerous directly attached disks.
Separate the disk space dedicated to tempdb from user databases.
Create many files to maximize disk ...
0
well yet it works! :) i did one more time the whole process and in the second group AG2 on the Primary Global i did (if that can help someone oneday too..):
CREATE AVAILABILITY GROUP [DistributedGroupName]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
'AG1' WITH
(
LISTENER_URL = 'TCP://ListenerAG1:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = ...
0
This is from Microsoft books online :
Initialize secondary availability groups in a distributed availability group
Distributed availability groups were designed with automatic seeding to be
the main method used to initialize the primary replica on the second
availability group. A full database restore on the primary replica of the
second availability group ...
1
If you only have one drive, you won't gain performance by splitting it logically but you said you want to split the drive into logical drives for logs and data so if one runs out of room it will not cripple the others' content. However, if either your data drive or your log drive or your tempdb drive is out of space then you are down. I would instead keep on ...
2
Create a new filegroup. Duplicate the tables you want to keep into the new filegroup. Copy the data you want to keep to these new tables using bulk insert instructions with optimizations for ordered data. Drop the old tables.
When all tables are processed drop the old filegroup, if possible. If not, move the objects and data back again then drop the new ...
0
NOT EXISTS is more readable and does not need to go through to get a full count.
BEGIN
IF (NOT EXISTS(SELECT 1
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
AND TABLE_NAME = 'foo'
AND COLUMN_NAME = 'bar' ))
THEN
ALTER TABLE `foo` ADD COLUMN `bar` varchar(32) NOT NULL;
...
0
The list on the page you reference is the versions of SSRS that are supported to upgrade FROM. So, basically any version of SSRS from 2008 onwards is supported to upgrade to SQL 2017.
https://docs.microsoft.com/en-us/sql/reporting-services/install-windows/migrate-a-reporting-services-installation-native-mode?view=sql-server-ver15
...one of the following ...
Top 50 recent answers are included
