Hi Can any one advice how to make aliases for AutoSys machine name
something like -1045_VM_AMDGC_APP_DEV2 i am using the whole name and unable to find how to make aliases.
As a work around i insert a machine that points to a random dns and then update command to point to an existing agent machine to create an alias. is okay or is there a simpler way to do it.
I tried to use insert alias with node name pointing to the real machine but does not allow like that and gives machine already exists error even if the machine name is different.
insert_machine:ALiasname
type:a
nodename:vmsometjing..network.network
You can achieve that with virtual machines:
insert_machine: aliasname
type: v
machine: 1045_VM_AMDGC_APP_DEV2
Then you just need to update the job to point to the aliasname and all will be good, make sure when you delete the machine to update the definition of the virtual as well.
Related
I built a galera cluster out of three Pi. The users are automatically copied to all servers. The databasename, tablename, columnname too. But they are always empty. So a select on a table only returns entries on the created server. I am absolutely new to the cluster area. Thank you if someone can help LG
I assume that you are using mariadb.
Make sure there is Primary Component in the cluster, you may check in using Status variable wsrep_cluster_status
Also, please always check the server log, if something goes wrong. Log is your friend.
We have an application that is connecting to a Galera Cluster we are using a connection string with multiple hosts. I.E. with MariaDB Connector J. If the first host in the connection string becomes a donor and we issue an insert statement the insert will hang until the donor stops being a donor and resumes as a regular node. We are using MariaDB Connector J is there any way to automatically switch to another host when the initial Host becomes a Donor? We tried using the keyword sequential, but it did not work in this case. Is there a setting in Galera that will allow a donor to immediatly execute an insert statement and return? How is this normally handled? Resynch can take up to 20 minutes and our program cannot pause that long.
I think I might have figured it out. I changed the setting wsrep_sst_donor_rejects_queries to on. With the keyword sequential, this allowed the driver to skip the donor and move to the next up host. If anyone has any alternative solution please post it. I thought I should post my solution so it would help others facing a similar challenge.
Can someone point me to the relevant BOL info for this (odd to me) behavior?
I had to join the prod & staging copies of the same table (same db name, diff servers), for a quick query. So I simply needed a fully-qualified join.
This one errors:
SELECT top 10 *
FROM [172.26.196.105\Staging].[DbName].[dbo].[TableName]
This one works:
SELECT top 10 *
FROM [USCASQL01\STAGING].[DbName].[dbo].[TableName]
Edit: clarification ... obviously not a join, these selects were simply me assembling the fully qualified name of my staging db/table. This is not a linked server, but the one I'm connected to.
These, of course, refer to the same instance. I used the IP address\InstanceName since that is what displays in my Object Explorer, it returned an error - "Could not find server 'IP address\InstanceName' in sys.servers." True enough, sys.servers stores the computerName\InstanceName, which works.
Why would one work and not the other? IOW, Why can't it resolve the IP/Instance name in TSQL when it resolves it just fine in the Object Explorer? BTW, we frequently are storing IP's in sys.servers, this one just happened not to be.
Also, I recall from SQL Server7 (way back in the day), a utility that would allow you to create friendly-name aliases for ip's. Can't find it now, does it still exist?
TIA
This is because the first part of a four part qualified name is a reference to a linked server by name, not by an IP or network name. So, if you don't have the linked server set up, then you get the error you encountered.
For adding linked servers, you want to be looking at sp_addlinkedserver.
This is the BOL Page that describes how the four part names work.
I need to rename a lot of similar named job names so i want to run an update statement to change the name column of msdb..sysjobs.
Editing system tables is something i am pretty aware of, but changing job names doesn't feel that dangerous, because i think the job_id is what counts. Is it safe to do it in this case?
I am using sql server 2008.
When you have the same jobs running in multiple environments, it's a better practice to refer to jobs by name rather than by ID, because a job with the same name will be created with a different ID in every environment.
If you change the name of the jobs, make sure that any scripts you use to manipulate those jobs also use the new name.
I think there is nothing to worry about, you can modify it.
Please find detail about sysjobs here.
It is NOT save to just rename it. Using sql profiler shows, that renaming a package using the object exlorer will start several procedures. It will create a new package using sp_add_dtspackage and drop it later using sp_drop_dtspackage. The package id is although set using a parameter, so setting it random really seems to be a potential risk.
I'm trying to pull user data from 2 tables, one locally and one on a linked server, but I get the wrong results when querying the remote server.
I've cut my query down to
select * from SQL2.USER.dbo.people where persId = 475785
for testing and found that when I run it I get no results even though I know the person exists.
(persId is an integer, db is SQL Server 2000 and dbo.people is a table by the way)
If I copy/ paste the query and run it on the same server as the database then it works.
It only seems to affect certain user ids as running for example
select * from SQL2.USER.dbo.people where persId = 475784
works fine for the user before the one I want.
Strangely I've found that
select * from SQL2.USER.dbo.people where persId like '475785'
also works but
select * from SQL2.USER.dbo.people where persId > 475784
brings back records with persIds starting at 22519 not 475785 as I'd expect.
Hope that made sense to somebody
Any ideas ?
UPDATE:
Due to internal concerns about doing any changes to the live people table, I've temporarily moved my database so they're both on the same server and so the linked server issue doesn't apply. Once the whole lot is migrated to a separate cluster I'll be able to investigate properly. I'll update the update once this happens and I can work my way through all the suggestions. Thanks for your help.
The fact that LIKE operates is not a major clue: LIKE forces integers to string (so you can say WHERE field LIKE '2%' and you will get all records that start with a 2, even when field is of integer type). Your incorrect comparisons would lead me to think your indexes are corrupt, but you say they work when not used via the link... however, the selected index might be different depending on the use? (I seem to recall an instance when I had duplicate indexes and only one was stale, although that was too long ago to recall the exact cause).
Nevertheless, I would try rebuilding your index using the DBCC DBREINDEX (tablenname) command. If it turns out that doing so fixes your query, you may want to rebuild them all: here is a script for rebuilding them all easily.
Is dbo.people a table or a view? I've seen something similar where the underlying table schema had been changed and dropping and recreating the view fixed the problem, although the fact that the query works if run directly on the linked server does indicate something index based..
Is the linked server using the same collation? Depending on the index used, I could see something like this perhaps happening if the servers were not collation compatible, but the linked server was set up with collation compatible (which tells Sql Server it can run the query on the remote server).
I would check the following:
Check your definition on the linked server, and confirm that SQL2 is the
server you expect it to be
Check and compare the execution plans both from the remote and local servers
Try linking by IP address rather than name, to ensure you have the proper machine
Put the code into a stored procedure on the remote machine, and try calling that instead
Sounds like a bug to me - I;ve read of some issues along these lines, btu can't remember specifically what. What version of SQL Server are you running?
select * from SQL2.USER.dbo.people where persId = 475785
for a PersID which fails how does:
SELECT *
FROM OpenQuery(SQL2, 'SELECT * FROM USER.dbo.people WHERE persId = 475785')
behave?