ApsaraDB RDS:Create a database

Lorsque vous créez une base de données sur la page Databases d'une instance ApsaraDB RDS for SQL Server, le message d'erreur Specified DB name already exists in the This instance. s'affiche. Le code d'erreur est InvalidDBName.Duplicate.

Une base de données portant le même nom existe déjà sur l'instance. Vous ne pouvez pas créer une base de données dont le nom est identique à celui d'une base de données existante.

De plus, la page Databases d'une instance ApsaraDB RDS for SQL Server affiche uniquement les bases de données dont l'état est ONLINE. Les bases de données qui ne sont pas dans l'état ONLINE (telles que RESTORING, RECOVERING ou OFFLINE) ne sont pas affichées dans la console. Par conséquent, vous pouvez croire à tort que la base de données n'existe pas, ce qui peut entraîner des échecs de création.

1. Connectez-vous à l'instance ApsaraDB RDS for SQL Server à l'aide de SSMS.

2. Exécutez l'instruction SQL suivante pour interroger les bases de données non système de l'instance et leurs états :

   SELECT
       [name] AS DatabaseName,  -- The name of the database
       state_desc AS StateDescription,  -- The current state of the database, such as ONLINE, OFFLINE, or RECOVERING
       recovery_model_desc AS RecoveryModel  -- The recovery model of the database, such as SIMPLE or FULL
   FROM
       sys.databases
   WHERE
       database_id > 4; -- Filter out system databases

   Le résultat suivant est renvoyé à titre d'exemple. Vous pouvez vérifier si une base de données portant le même nom existe et consulter l'état actuel de la base de données.

   DatabaseName    StateDescription    RecoveryModel
   jmdb            ONLINE              FULL
   jmdb200         RECOVERING          FULL

3. Si une base de données portant le même nom existe mais n'est pas dans l'état ONLINE, résolvez le problème en fonction des scénarios suivants :

   • Scénario 1 : Vous choisissez de ne pas mettre la base de données en ligne lors de la restauration des données de sauvegarde depuis OSS

     • Cause

       Lorsque vous restaurez des données de sauvegarde depuis OSS vers une instance ApsaraDB RDS for SQL Server, si vous sélectionnez l'option Do not bring the database online (for additional differential or log backups), la base de données reste dans un état autre que ONLINE.

       Cette option se trouve dans la section Migration Plan à l'étape 3. Import Data du guide Import Guide, qui s'affiche après avoir cliqué sur Migrate OSS Backup Data to RDS sur la page Backup and Restoration dans le volet de navigation de gauche de la console RDS.

     • Solution

       Si vous devez toujours télécharger des fichiers de sauvegarde incrémentielle, mettez la base de données en ligne dans l'onglet Cloud Migration Records of Backup Data une fois la restauration terminée. Si vous n'avez plus besoin de restaurer des données incrémentielles, vous pouvez directement mettre la base de données en ligne.

       Dans ce cas, dans l'onglet Cloud Migration Records of Backup Data, l'état de la tâche est Waiting, le type de tâche est Do not bring the database online (for additional differential or log backups) et la description de la tâche est Waiting for online.

       Si la base de données n'est plus nécessaire et doit être recréée, mettez-la en ligne, supprimez la base de données, puis créez-la à nouveau.

   • Scénario 2 : La base de données passe à l'état RECOVERING car l'espace journal est saturé

     • Cause

       L'espace journal est saturé et les journaux ne peuvent pas être écrits. Par conséquent, la base de données passe à l'état RECOVERING. Vous pouvez vérifier les journaux d'erreurs de l'instance pour confirmer le problème :

       3/16/2024 2:05:35 AM    spid128    During undoing of a logged operation in database 'db_logistics', an error occurred at log record ID (1:88854:14712:2). Typically, the specific failure is logged previously as an error in...
       3/16/2024 2:05:35 AM    spid128    Error: 3314, Severity: 21, State: 3.
       3/16/2024 2:05:35 AM    spid128    The transaction log for database 'xxx' is full due to 'LOG_BACKUP'.
       3/16/2024 2:05:35 AM    spid128    Error: 9002, Severity: 17, State: 2.
       3/16/2024 2:05:35 AM    spid128    The transaction log for database 'xxx' is full due to 'LOG_BACKUP'.

     • Solution

       • Si l'espace de stockage de l'instance est saturé et que l'espace journal ne peut pas être étendu, augmentez la capacité de stockage de l'instance puis redémarrez manuellement l'instance. Après le redémarrage, la base de données poursuit le processus de récupération. Une fois la récupération terminée, la base de données revient à l'état ONLINE.

       • Si une limite de croissance est définie pour le fichier journal de la base de données et que l'espace journal est saturé alors que l'espace de stockage de l'instance ne l'est pas, il vous suffit d'augmenter la limite de taille du fichier journal. Vous n'avez pas besoin de redémarrer l'instance. Pour ajuster la limite de taille du fichier journal, procédez comme suit :

         Dans l'Explorateur d'objets de SQL Server Management Studio (SSMS), faites un clic droit sur la base de données, par exemple jmdb, et sélectionnez Properties.

         Dans le volet de navigation de gauche de la boîte de dialogue Database Properties, sélectionnez la page Files. Dans le tableau Database files, recherchez le fichier journal dont le File Type est LOG, puis cliquez sur le bouton ... dans la colonne Autogrowth / Maxsize pour ajuster les paramètres de croissance automatique et la taille maximale du fichier journal.

         Dans la boîte de dialogue Change Autogrowth for jmdb_log, sélectionnez Enable Autogrowth, définissez File Growth sur In Megabytes et saisissez une valeur de croissance, par exemple 64, définissez Maximum File Size sur Limited to (MB) et saisissez une taille de fichier maximale, par exemple 2 097 152, ce qui indique 2 To, puis cliquez sur OK.

       Si la base de données n'est plus nécessaire et doit être recréée, attendez qu'elle passe à l'état ONLINE, supprimez la base de données, puis créez-la à nouveau.

   • Scénario 3 : La base de données est définie manuellement sur l'état OFFLINE

     • Cause

       Un administrateur a peut-être défini manuellement la base de données sur l'état OFFLINE.

     • Solution

       Utilisez la procédure stockée sp_rds_set_db_online pour remettre la base de données dans l'état ONLINE :

       USE master;
       GO
       EXEC sp_rds_set_db_online 'Database name';
       GO

       Si la base de données n'est plus nécessaire et doit être recréée, attendez qu'elle passe à l'état ONLINE, supprimez la base de données, puis créez-la à nouveau.