It is possible to affect the sources (i.e. monitored ports) if the aggregate traffic exceeds the capability of the destination (i.e the monitoring port). I don't have the reference I was initially thinking of, but here's another: Back pressure from a SPAN port.
So imagine you have server on a ten-gig port that you want to SPAN to a packet capture device (or IDS/IPS, etc.). The monitoring device is also on a ten-gig interface.
Remember that when you set up a SPAN, you have the option of SPANning transmit (out of the switch interface towards the server), or receive (from the server into the switch) , or both. Normally we would want to see both sides of a conversation, so we'd choose to SPAN both the transmit and received.
Now imagine that the server is very busy, and both it's transmit and receive streams are quite full, consistently above 5-gig in each direction.
You now want to send TWO, greater-than-5-gig streams to the monitoring device via the SPAN destination port. The total traffic being sent towards the SPAN destination is greater than 10-gig. But, that interface is ONLY 10-Gig towards the monitoring device. So what happens? I recall that Cisco's docs said that initially, packets would be dropped from the transmit buffer of the interface towards the monitoring device (i.e. the SPAN destination transmit buffer). However, in the case of long-duration, sustained traffic streams, eventually the ability of the switch to drop excess traffic from the transmit buffer will be exhausted (which does not, and did not at the time, make sense to me), and then the switch will begin to use other mechanisms to decrease the flow, including 'back pressure' using 802.3x PAUSE frames being sent to the source ports.
And you have now impacted your source traffic. Bad things happen.
This problem is/was especially significant to a large, high-speed very low latency network, that had many sources for the SPAN. Which was a major consideration and resulted in replacing the use of SPAN sessions having many sources for optical TAPS, feeding aggregation switches with inbound ACLs (filtering for interesting traffic), then trunking that inbound traffic to multiple 10-Gig specialized packet consumers (for data archive and analysis needs).
Moral of the story: if you are intending to use many SPAN sources, be confident that the aggregate bandwidth of BOTH tx and rx is less than the bandwidth to your capture device.
Here's a decent treatise on using SPAN ports