Perform the below steps to rollback the patch, if required

• Disable Auditing
  sp_configure “auditing”, 0

• Stop Replication Server, Backup server and Foglight Agents

• Re-start ASE in single user mode by specifying the -m option in RUN File. When starting ASE, you should see the below message in error log
  00:0002:00000:00002:2024/08/13 16:08:05.91 server *** WARNING ******************
  00:0002:00000:00002:2024/08/13 16:08:05.91 server ASE booted single user mode – updates allowed to system catalogs
  00:0002:00000:00002:2024/08/13 16:08:05.91 server WARNING ***************

• Run sp_downgrade_esd on each database. You need not downgrade temporary databases. These include tempdb as well as user-created temporary databases, as they are re-created from a template database when Adaptive Server starts.

Note: Please perform sp_downgrade_esd on all of your non-temporary databases, then downgrade the master database last.

Shown below is an example where the entire instance was downgraded from SP04 PL04 to SP04 PL02
1> use master
2> go
1> select @@version
2> go
—————————————————————————————————————————————————————————————————————————————————————
Adaptive Server Enterprise/16.0 SP04 PL04/EBF 30650 SMP/P/x86_64/SLES 12.4/ase160sp04pl04x/3585/64-bit/FBO/Tue Feb 14 09:59:39 2023
(1 row affected)

1> select name from sysdatabases
2> go
name
——————————
SYBTORE_SYS_DEV_RS09_RSSD
audit_arch
dbccdb
master
model
questdb
sa_tempdb
sybsecurity
sybsystemdb
sybsystemprocs
tempdb
tempdb_surveillance
test_db
(13 rows affected)

1> sp_downgrade_esd SYBTORE_SYS_DEV_RS09_RSSD, “SP04 PL02”
2> go
Reverting database ‘SYBTORE_SYS_DEV_RS09_RSSD’ to SP04 PL02.
Running CHECKPOINT on database ‘SYBTORE_SYS_DEV_RS09_RSSD’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘SYBTORE_SYS_DEV_RS09_RSSD’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd audit_arch, “SP04 PL02”
2> go
Reverting database ‘audit_arch’ to SP04 PL02.
Running CHECKPOINT on database ‘audit_arch’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘audit_arch’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd dbccdb, “SP04 PL02”
2> go
Reverting database ‘dbccdb’ to SP04 PL02.
Running CHECKPOINT on database ‘dbccdb’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘dbccdb’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd model, “SP04 PL02”
2> go
Reverting database ‘model’ to SP04 PL02.
Running CHECKPOINT on database ‘model’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘model’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd sybsecurity, “SP04 PL02”
2> go
Reverting database ‘sybsecurity’ to SP04 PL02.
Running CHECKPOINT on database ‘sybsecurity’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘sybsecurity’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd sybsystemdb, “SP04 PL02”
2> go
Reverting database ‘sybsystemdb’ to SP04 PL02.
Running CHECKPOINT on database ‘sybsystemdb’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘sybsystemdb’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd sybsystemprocs, “SP04 PL02”
2> go
Reverting database ‘sybsystemprocs’ to SP04 PL02.
Running CHECKPOINT on database ‘sybsystemprocs’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘sybsystemprocs’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd test_db, “SP04 PL02”
2> go
Reverting database ‘test_db’ to SP04 PL02.
Running CHECKPOINT on database ‘test_db’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘test_db’ is now suitable for use by SP04 PL02.
(return status = 0)

1> sp_downgrade_esd master, “SP04 PL02”
2> go
Reverting database ‘master’ to SP04 PL02.
Running CHECKPOINT on database ‘master’ for option ‘downgrade’ to take effect.
Downgrade is complete.
Database ‘master’ is now suitable for use by SP04 PL02.
(return status = 0)

• Shutdown ASE

• Under /sybdba01/sybase (or equivalent directory) rename ase_16.0 to ase_16.0_. So in your install, you will perform the below move
  cd /sybdba01/sybase
  mv ase_16.0 ase_16.0_sp04_pl05

• Move SP04 PL02 backed up directory under ESD_Rollback to ase_16.0 under Sybase Software File system, as shown below
  cd ESD_Rollback/
  ls -ltr
  total 29280
  -rwxr-x—. 1 sybdba sybase 1024 Sep 28 2023 RUN_SYBTORE_SYS_DEV_DS02_BK
  drwxr-x—. 23 sybdba sybase 4096 Sep 28 2023 ase_16.0_SP04_PL02_EBF29987
  -rwxr-x—. 1 sybdba sybase 1235 Sep 28 2023 RUN_SYBTORE_SYS_DEV_DS02
  -rw-r—–. 1 sybdba sybase 19036 Oct 4 2023 SYBTORE_SYS_DEV_DS02.cfg
  -rw-r—–. 1 sybdba sybase 2336768 Oct 9 2023 SYBTORE_SYS_DEV_RS09_RSSD.master.20231009.065009.dmp
  -rw-r—–. 1 sybdba sybase 26529792 Oct 9 2023 SYBTORE_SYS_DEV_RS09_RSSD.sybsystemprocs.20231009.065009.dmp
  -rw——-. 1 sybdba sybase 1076877 Oct 9 2023 SYBTORE_SYS_DEV_RS09_RSSD_restoremsgs.ebf
  drwxr-x—. 15 sybdba sybase 4096 Oct 9 2023 rep_16.0_EBF_30655_SP04_PL04_rs160sp04pl04

mv ase_16.0_SP04_PL02_EBF29987 ../ase_16.0

• Re-start ASE in regular mode by removing ‘-m’ switch from RUN file, which will start the instance in SP04 PL02 binary

• Run installmaster, installmodel, installcommit, installsecurity, installdbccdb scripts

• Restore the messages by loading _restoremsgs.ebf from ESD_Rollback directory, as shown in below example
  isql -Usa -S SYBTORE_SYS_DEV_DS02 -w2000 -X -i /sybdba02/sybase/ESD_Rollback/SYBTORE_SYS_DEV_DS02_restoremsgs.ebf

• After the downgrade, all the versions should be at SP04 PL02, as shown below
  1> select @@version
  2> go
  —————————————————————————————————————————————————————————————————————————————————————
  Adaptive Server Enterprise/16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/FBO/Thu Mar 17 21:44:05 2022
  (1 row affected)

1> sp_version
2> go
Script Version Status
——————- ———————————————————————————————————————- ——–
ADO.NET MDA Scripts 16.0.04.02.1019/Thu Feb 17 UTC 14:35:44 2022 Complete
ODBC MDA Scripts 16.0.04.02.1019/Tue Feb 15 UTC 16:42:49 2022 Complete
installcommit 16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:15:51 2022 Complete
installdbccdb 16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:15:51 2022 Complete
installjdbc jConnect (TM) for JDBC(TM)/16.0 SP04 PL02 (Build 27518)/P/EBF30180/JDK 1.8.0/jdbcsp04/OPT/Tue Feb 15 01:29:04 PST 2022 Complete
installmaster 16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:15:51 2022 Complete
installmodel 16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:15:51 2022 Complete
installsecurity 16.0 SP04 PL02/EBF 29987 SMP/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:15:51 2022 Complete
montables 16.0/29987/P/x86_64/SLES 12.4/ase160sp04pl02x/3545/64-bit/OPT/Thu Mar 17 20:05:28 2022 Complete
(9 rows affected)
(return status = 0)

• Run the Ansible job Sybase Action – SYB_Enable_Audit_Settings to re-enable all audit settings

There are actually 3 tables which will need to be copied over and synced up, they are syslogins, syssrvroles and sysloginroles.

The below steps will vary a bit but for example if you are upgrading from Sybase version 12 to 15 then you would do the following steps, for other ASE versions you might need to change the temp table a bit:

Source Server

The first step is to bcp out these tables (syslogins, syssrvroles and sysloginroles) from the source Sybase server and copy the files over to the destination.

e.g bcp master..syslogins out syslogins.out -U<Username> -S<Servername> -n -X

From destination server scp the files across e.g.

scp zkc3yit@gbzzyxsyordad02.gbcaydc.baml.com:/tmp/t/* /tmp/t

.

.

.

Destination Server

Syslogins

• Create the temporary syslogins table on the new server
  sp_configure ‘allow updates to system tables’,1
  go
  USE tempdb
  go
  /*drop table dbo.temp_syslogins
  go
  */
  CREATE TABLE dbo.temp_syslogins
  (
  suid        int             NOT NULL,
  status      smallint        NOT NULL,
  accdate     datetime        NOT NULL,
  totcpu      int             NOT NULL,
  totio       int             NOT NULL,
  spacelimit  int             NOT NULL,
  timelimit   int             NOT NULL,
  resultlimit int             NOT NULL,
  dbname      sysname          NULL,
  name        sysname     NOT NULL,
  password    varbinary(130)   NULL,
  language    varchar(30)     NULL,
  pwdate      datetime        NULL,
  audflags    int             NULL,
  fullname    varchar(30)     NULL,
  srvname     varchar(30)     NULL,
  logincount  smallint        NULL,
  procid      int             NULL,
  lastlogindate datetime      NULL,
  crdate      datetime        NULL,
  locksuid    int             NULL,
  lockreason  int             NULL,
  lockdate    datetime        NULL,
  lpid           int            NULL,
  crsuid         int            NULL
  )
  LOCK ALLPAGES
  Go
  
  You may need to tweak the column types depending on which version of Sybase you are importing from, check their source syslogins table to double check.
  

• Now bcp in the logins which was bcp’d out on the old Sybase server
  bcp tempdb..temp_syslogins in syslogins.out -Usa -P -SMICOY2 -n -X
  
  
• Make a note of the highest suid currently in master..syslogins
  
  
• Check to see which logins already exist in master..syslogins and identify any clashes
  select s.suid, t.* from tempdb..temp_syslogins t, master..syslogins s
  where t.name =s.name
  go
  
  Make a careful note where there is a discrepancy in suid’s. If any entry in source has a higher suid that the current highest suid in master..syslogins (e.g. if the highest current suid is 7 and ipgbmsed2 is 7 in master..syslogins but 8 in temp-syslogins) then you need to make a note to remove any special privileges away from suid 8 in temp_sysloginroles later on, if it has any. If the suid is within the current highest suid’s then it will be removed automatically in the delete before the insert, so just ignore.
  
  also run
  
  select s.name, t.name, t.*
  from tempdb..temp_syslogins t, master..syslogins s
  where t.suid =s.suid
  and t.name not in (select name from master..syslogins)
  go
  
  Here if you have a situation where an SUID in source clashes with a new one on the destination (i.e they have different names and the source name does not exist in destination) then you will need to increment the suid number in the temp syslogins and also temp sysloginroles table later on.
  
  
• From the second part above Increase the suid of any source login which clashed with destination
  update temp_syslogins
  set suid=3006
  where suid=6
  go
  
  
• Delete existing logins which match by name
  delete from tempdb..temp_syslogins
  where name in (
  select t.name from tempdb..temp_syslogins t, master..syslogins s
  where t.name =s.name
  )
  go
  

• Now copy the syslogins over to the master..syslogins table
  insert into master..syslogins
  select * from tempdb..temp_syslogins
  go
  

.

.

Syssrvroles

• Create the temp_syssrvroles table
  USE tempdb
  go
  CREATE TABLE tempdb..temp_syssrvroles
  (
      srid       int            NOT NULL,
      name       varchar(30)    NOT NULL,
      password   varbinary(128) NULL,
      pwdate     datetime       NULL,
      status     smallint       NULL,
      logincount smallint       NULL,
       locksuid int            NULL,
  lockreason  int           NULL,
  lockdate   datetime       NULL
  )
  go
  

• bcp in the entries from source
  bcp tempdb..temp_syssrvroles in c1p16_sysroles.out -Usa -P -SMICOY2 -n -X
  

• Check to see if there are any clashing srid’s in the source compared to destination, it should be ok from ASE15.7 to 16
  Select s.srid as master_srid, s.name as master_name,
  t.srid as source_srid, t.name as source_name, t.*
  from tempdb..temp_syssrvroles t, master..syssrvroles s
  where t.srid=s.srid
  go
  
  IF there are any clashes from above, which from 15.7 to 16 there should not be, then Update any srid’s which conflict with existing srid’s in master..sysrvroles e.g.
  update tempdb..temp_syssrvroles
  set srid= 133 where srid=33
  go
  
  
• Check to see if there are clashing role names in the source to destination
  Select s.srid as master_srid, s.name as master_name,
  t.srid as source_srid, t.name as source_name, t.*
  from tempdb..temp_syssrvroles t, master..syssrvroles s
  where t.name =s.name
  go
  
  If there are any clashes from the above query then we delete the srid from the temp table, we will also later need to update sysloginroles to use the srid which already exists in master.
  delete from temp_syssrvroles
  where srid=34
  go
  

• Delete the srvroles which already exist in master from the temp table.
  delete from tempdb..temp_syssrvroles
  where srid <=33 –Biggest srid currently in master..syssrvroles is 33
  go
  

• Copy the roles into master.syssrvroles
  insert into master..syssrvroles
  select * from tempdb..temp_syssrvroles
  go

.

.

Sysloginroles

• Create the sysloginroles table
  USE tempdb
  go
  CREATE TABLE dbo.temp_sysloginroles
  (
  suid   int      NOT NULL,
  srid   int      NOT NULL,
  status smallint NOT NULL,
  predid int      NULL
  )
  Go
  

• BCP in the entries from source
  bcp tempdb..temp_sysloginroles in c1p16_sysloginroles.out -Usa -P -SMICOY2 -n -X
  
  
• Update the same suid as you did for syslogins
  update tempdb..temp_sysloginroles
  set suid = 3006
  where suid=6
  go
  
  
• Delete any suid’s from temp_sysloginroles which already existed at the start in master..syslogins and master..sysloginroles
  delete from tempdb..temp_sysloginroles
  where suid <=8 –highest suid recorded earlier
  go
  
  
• Delete any suid’s from temp_sysloginroles which were previously a mismatch between master..syslogins and temp_syslogins
  delete from tempdb..temp_sysloginroles
  where suid in (10)
  go
  

• Update any srid number which you had to update previously in the syssrvroles step e.g.
  update tempdb..temp_sysloginroles
  set srid= 133
  where srid=33 — Updated srid from tempdb..syssrvroles
  go
  
  
• If there were any incidents of the same role name having different srid’s in syssrvroles (the second check) then you need to update the srid:
  update temp_sysloginroles
  set srid=33
  where srid=34
  go
  
  
• Delete any rows from temp_sysloginroles which doesn’t have a matching suid in master..syslogins
  delete from tempdb..temp_sysloginroles
  where suid not in (select suid from master..syslogins)
  
  
• Make sure everything looks ok
  select * from tempdb..temp_sysloginroles
  go
  

• Now Copy the roles into master.sysloginroles
  insert into master..sysloginroles
  select * from tempdb..temp_sysloginroles
  go
  
  
• Remove Update to system tables
  sp_configure “allow updates to system tables”, 0
  go

.

.

.

Synchronize Logins

The next steps relate to synchronizing the suids after you have loaded the old database into the new server.

• First thing is to enable updates to system catalogs
  sp_configure ‘allow updates to system tables’,1
  go
  
  
• Then if you had to alter/increment any suid’s in syslogins earlier then you will also need to do this in the sysusers for any database that has suid of e.g 6:
  update sysusers set suid=3006
  where suid=6
  go
  
  
• Next check whether there are any aliases set up without matching entries in syslogins:
  select * from sysalternates
  where suid not in (select suid from master..syslogins);
  go
  
  If you find any entries which do not match with anything in syslogins then they should be deleted from sysalternates:
  delete from sysalternates
  where suid not in (select suid from master..syslogins)
  go

• The next check is to find situations where the same name in syslogins and sysusers has a different suid.
  select l.suid ‘Login suid’,u.suid ‘User suid’,l.name ‘Login name’, u.name ‘User name’
  from
  master..syslogins l, sysusers u
  where l.name = u.name and l.suid != u.suid and u.name != “dbo”
  go
  
  If this finds any mismatches then the following query will resync the suids in the user database with the suid’s in syslogins.
  update sysusers
  set u.suid = l.suid
  from sysusers u, master..syslogins l
  where l.name=u.name
  go
  
  
• A follow on check is to see whether there are any users who have a different name to their syslogins name but with the same suid’s.
  select l.suid,u.suid,l.name, u.name from master..syslogins l, sysusers u
  where l.suid = u.suid and l.name != u.name and u.name != “dbo”
  go
  
  if that returns some rows then they need to be deleted from sysusers with the following query:
  delete from sysusers
  where suid in (select suid from master..syslogins)
  and name not in (select name from master..syslogins)
  and name != “dbo”
  go
  
  
• You should also check for any users in sysusers which do not match anything in syslogins
  select * from sysusers u
  where u.suid not in (select suid from master..syslogins)
  and name != “dbo”
  and suid > 0
  go
  
  These can be removed with
  delete from sysusers
  where suid not in (select suid from master..syslogins)
  and name != “dbo”
  and suid > 0
  go
  
  
• Disable updates to system tables
  sp_configure ‘allow updates to system tables’,0
  go
  
  

To restore a failed master database, perform the following steps:

1. Run dataserver with the –b and –d options to create a new master device:
   dataserver -d /dev/rsd1b –b 100M
2. Start SAP ASE in single-user mode:
   startserver -f RUN_SYBASE –m
3. You can use the master database, but presently it doesn’t have any references
   to any user databases or sybsystemprocs.
   If master was expanded beyond its default size, run alter database to extend it.
4. Update the backup server name in sysservers if it isn’t SYB_BACKUP:
   begin transaction
   update sysservers set srvnetname = “PROD_BACKUP”
   where servname = “SYB_BACKUP”
   commit transaction
5. Load the backup of the master database; after the load completes, it will shut
   down SAP ASE automatically:
   load database master from “/full/path/name/master.dump”
6. Start SAP ASE in single-user mode, and check that all databases/devices/logins
   appear to be restored correctly.
7. If everything appears okay, you’re nearly done. Shut down and restart SAP ASE
   normally, and skip to step 9.
8. If everything doesn’t appear okay, you have more work to do. If additional
   devices, databases, logins, or users of master were created after the last backup
   of master, you’ll need to re-create them.
   SAP ASE provides two commands to recover existing devices and databases to
   a restored master database:
   – disk reinit
   – disk refit
   Use disk reinit to recover devices created since the last dump of master; disk
   reinit restores information to sysdevices without reinitializing the device,
   which retains the data which is on the device. Values supplied to disk reinit
   should match values supplied to the original disk init command.
   
   The syntax for disk reinit follows:
   disk reinit name = logical_device_name,
   physname = physical_device_name,
   vdevno = virtual_device_number,
   size = number_of_pages | K | G | T
   disk refit is used after running disk reinit to rebuild the sysusages and sysdatabases tables in master from the database fragments found on the restored devices.

9. Assuming you need to run it, after executing disk refit, SAP ASE will automatically
   shut down the server. You should restart SAP ASE in single-user mode
   and verify that all databases are properly restored and are the correct sizes. Run
   dbcc checkalloc() on all recovered databases. If everything appears okay, shut
   down and restart SAP ASE normally. Any changes or additions to logins, configuration
   options, remote servers, remote logins, and roles will still need to be
   re-created.
   
   The moral of the story is to keep frequent backups of the master database! Best
   practice is to schedule a nightly backup of the master database. In addition, back
   up the master database after each command that affects disks, storage, databases,
   segments, logins, roles, and so on.

Since ASE15.7 SP100 you don’t need to worry about creating a database in the same sequence of data and log segments when loading a dump from another database, this is something which you had to do previously.

Now the only consideration is that you have enough space for data device and log device. So for example if you are loading from a database which was created in this sequence; Data 5, Log 5, Log 5, Data 15, Log 5 and finally Data 10. then all you need to do now is;
Create database dbload with data on datadevice=”30M” and log on logdevice=”15M”
and then load the database, the load then sorts the fragments into the correct order automatically.

Sybase has a relatively new backup called cumulative which backs up all the changes in the database since the last Full Backup/Dump and can be used in between Full Backups and Tran backups to give greater flexibility, especially on large databases. It is similar to the Differential Backup in SQL Server

To enable this backup for a database you must first enable the “allow incremental dumps” option in the database: e.g sp_dboption <dbname>, ‘allow incremental dumps’, true

You can then issue the cumulative backup command as long as there is an existing valid Full Dump backup:
dump database <dbname> cumulative to “/tmp/tore1-cum.dmp”
go

To load the cumulative dump the syntax is:
load database <dbname> cumulative from “/tmp/tore1-cum.dmp”
go

Backup / Restore order

In terms of using the cumulative backup you could for example take a weekly Full backup, then daily cumulative backups and hourly transaction log backups.

So in a recovery situation you would first recover the Full Backup, then the latest Cumulative Backup and finally the transaction log dumps up to the required point in time.

Pre-Steps

The Repserver interfaces file will need entries for both Primary and Replicate Dataservers and the Primary Dataserver’s interface file will need an entry for the Repserver.

• Lets first set some things set up and make a note of various user accounts and passwords.
  Make a note of the various logins passwords you need; Dataserver sa login, Dataserver maint login (which needs to be created on both dataservers), Replication server sa login and Replication server Repagent login. 
  Unless you have an account with the same name/password on all three servers (RepServer and two dataservers), e.g sa, you will also need to create a RepAdmin Login on the RepServer and two Dataservers giving it sa_role and replication_role on the Dataservers and sa role on the RepServer. This login MUST be used when defining the subscription later on. 
  If it already exists drop the maint user from the primary and instead alias the maint user to dbo, e.g sp_addalias Database_maint, dbo
  
  
• Create the connections to the source(pubs2) and replicant(pubs2_rep) databases using rs_init, marking pubs2 as being replicated.
  
  
• After the connections are created you need to disable the firing of any triggers on the replicate side with:
  Alter connection to <replicate server>.<replicate db>
  Set ‘dsi_keep_triggers’ to ‘off’
  go

• Mark the whole Primary/Source database (e.g pubs2) for replication with
  Sp_reptostandby pubs2, ‘all’
  go
  You can also just mark individual table(s) for replication with;
  use pubs
  go
  sp_setreptable table_name, true;
  
  
• If you are setting the whole database to replicate (sp_reptostandby) then you also need to enable warm standby transactions which enables/allows replication of DDL statements.
  sp_config_rep_agent pubs2,
  send_warm_standby_xacts,true
  go

• Make sure the repagent is up and running as that is needed for the dump marker to trigger below. This can be checked in the Primary Dataserver with sp_help_rep_agent and also on the RepServer with admin who. Another thing to check is for a valid secondary truncation point in the primary database. You can check this with dbcc gettrunc and look for the secondary trunc state, it should be 1 for valid. If its not then stop the rep agent, then run dbcc settrunc (‘ltm’, ‘valid’), then in the RSSD run rs_zeroltm <primary server>, <primary db> and then back in the primary db start up the repagent and again check for the secondary truncation point.

• Assuming the above is fine we now Create the Database replication definition using RepAdmin login:
  create database replication definition pubs2_rdf
  with primary at <Primary server>.<Primary DB>
  replicate ddl
  go

• Define subscription to database rep def using RepAdmin login:
  define subscription pubs2_sub
  for database replication definition pubs2_rdf
  with primary at <Primary server>.<Primary DB>
  with replicate at <Replicate server>.<Replicate DB>
  use dump marker
  go
  
  One very important thing to note with create or define subscription is that the Login you use to run this, either interactively or through a script, must exist on the primary (and secondary) dataserver and the RepServer with the same name and password.
  You can check the creation of the subscription in the RepServer errorlog, there should be a line saying “Placing marker in <Primary server>.<Primary db> log”
  
  

• Dump the Primary Database
  Once the dump is complete you should check the RepServer errorlog again, as soon as the dump marker gets processed there should be an entry in the log like:
  “Distributor for ‘<Primary server>.<Primary DB>’ received and processed enable marker. Distributing commands to replicates.
  Distributor for ‘<Primary server>.<Primary DB>’ received and processed dump marker.
  The DSI thread for database ‘<Replicate server>.<Replicate DB>’ is shutdown.”
  
  

• Now Load the dump into the Replicate DB and Online the database
  
  
• You now add the maint user as an alias to dbo (or equivalent permissions) for the replicate database, unless it has exactly the same suid on both servers in which case it will already be aliased to dbo but check this.
  
  
• Now remove the secondary truncation point from the replicate database with
  dbcc settrunc (‘ltm’, ‘ignore’)

• Resume connection to the replicant database dsi
  Resume connection to <Replicate server>.<Replicate DB>
  
  
  
• That should be it, you should now have database replication set up between pubs2 and pubs2_rep, which you can test by creating a new table and entering some data in pubs 2 and checking it gets created and sent across to pubs2_rep.
  
  
  
  BTW to allow replication of DDL statements you might need to enable ‘ddl in tran’ in the replicate database but I think this is already covered in the “Alter connection to <replicate server>.<replicate db>” Step but in case of any errors/issues just be aware of it.
  Use master
  go
  sp_dboption pubs2_rep, ‘ddl in tran’, true
  go